Re: kern/48797: Scale down cd9660 inode numbers by a factor of 32

[David Laight <david%l8s.co.uk@localhost>]

The following reply was made to PR kern/48797; it has been noted by GNATS.

From: David Laight <david%l8s.co.uk@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/48797: Scale down cd9660 inode numbers by a factor of 32
Date: Sun, 11 May 2014 23:37:10 +0100

 On Fri, May 09, 2014 at 06:15:00PM +0000, scdbackup%gmx.net@localhost wrote:
 > >Synopsis:       Scale down cd9660 inode numbers by a factor of 32
 ...
 > The inode numbers of sys/fs/cd9660 are computed from the byte
 > addresses of their ISO 9660 directory records. With single
 > session media, they are normally in the range of 36864 to a
 > few million.
 > 
 > But multi-session media have their directory records stored
 > in the youngest session. With DVD DL and BD media it is likely
 > that this session starts above 4 GiB.
 
 Is there any reason why the 'inode' numbers couldn't be offsets
 from the start of the final session?
 
 While slightly orthogonal to the rest of the discussion it might
 lead to fewer issues with the large numbers.
 
 For file handles (for NFS) would it be worth adding a short hash
 of an initial sector (as a random value) to help identify stale
 file handles after a server reboot?
 Even a 16bit one might help.
 
        David
 
 -- 
 David Laight: david%l8s.co.uk@localhost