Re: kern/48797

["Thomas Schmitt" <scdbackup%gmx.net@localhost>]

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

From: "Thomas Schmitt" <scdbackup%gmx.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/48797
Date: Mon, 12 May 2014 09:46:29 +0200

 >  Is there any reason why the 'inode' numbers couldn't be offsets
 > from the start of the final session?
 
 I thought about this too.
 
 But the ECMA-119 specs do not outrule that a directory record is
 stored below the start of the youngest session. E.g. that a
 directory from a previous session could be re-used.
 
 This is not the style of mkisofs or libisofs, which create whole
 new directory trees when adding a session. But it would be allowed.
 
 
 >  For file handles (for NFS) would it be worth adding a short hash
 
 First it should work with NFS and large inode numbers at all:
 kern/48799
 
 cd9660 is read-only. So stale nodes with cd9660 are only a problem
 if the whole filesystem gets exchanged underneath the NFS mount point.
 This would rather be a stunt, than a normal system situation.
 
 
 I am assessing the inner relations of cd9660 for preparing support for
 large files. In the beginning i looked at the inode number computation
 as a hack. It would really be, if the ino_t was 32 bit.
 But with a regular ino_t of 64 bit, several things in the code
 become easy and straightforward. So i changed my view on this.
 
 Further, as Martin Husemann mentioned:
 There are other filesystems which are prone to 64-bit inode numbers
 too, where they may be more hard to provoke than in cd9660.
 So cd9660 images like my tiny large.iso could be test objects
 for tools which needs mending. (Like it was with /bin/ls -i)
 
 One could do once with the inflated image
 http://scdbackup.webframe.org/large.iso.bz2:
 
   dd if=large.iso bs=2048 count=56 | bzip2 >large.iso.0.bz2
   dd if=large.iso bs=2048 skip=2114008 | \
                                      bzip2 >large.iso.2114008.bz2
 
 yielding
 
   -rw-r--r--  1 thomas  wheel        744 May  6 18:57 large.iso.0.bz2
   -rw-r--r--  1 thomas  wheel        745 May  6 18:57 large.iso.2114008.bz2
 
 And then with each test create a sparsely populated file with
 only a few hundred KB real storage consumption:
 
    bunzip2 <large.iso.0.bz2 >large.iso
    bunzip2 <large.iso.2114008.bz2 | \
       dd bs=2048 seek=2114008 of=large.iso
 
 Tested and MD5-proof.
 (Numbers 56 and 2114008 depend on insider knowledge about this particular
  ISO image. Other image, other numbers.)