[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
The following reply was made to PR kern/48797; it has been noted by GNATS.
From: "Thomas Schmitt" <scdbackup%gmx.net@localhost>
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:
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
dd if=large.iso bs=2048 count=56 | bzip2 >large.iso.0.bz2
dd if=large.iso bs=2048 skip=2114008 | \
-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.)
Main Index |
Thread Index |