iso9660 inodes beyond 4GB
PATCH 1/1 iso9660 inodes beyond 4GB
The ISO 9660 standard allows meta-data to be stored at almost any arbitrary byte on the file system. The current inode scheme uses the byte offset as the inode value making it easy to find the underlying block and block offset.
This scheme is subject to obvious integer overflow problems that prevents it from being able to reach meta-data beyond the 4GB boundary. Looking back through the archives, this problem was anticipated but discounted because mkisofs puts its meta-data near the beginning of the file system.
However, there are at least two common scenarios where meta-data must be located beyond the 4GB boundary. First, growisofs needs to add meta-data beyond the 4GB boundary when it merges a new session with an old session that ended beyond the 4GB boundary. The following URL has more information:
http://fy.chalmers.se/~appro/linux/DVD+RW/#isofs4gb
Second (and what prompted this patch) is that I've written two programs that together with cdrecord or growisofs allow arbitrarily large backups to span a multi-volume set of DVDs without the need for any intermediate files (much like the functionality of a tape drive). Because I only know the file lengths near the end of each burn, I have to write the meta-data near the end of the DVD. The following URL has more information:
To support these types of DVDs, the inode scheme for isofs must be changed. The patch I'm submitting for review provides one such comprehensive inode scheme. It assigns inode numbers sequentially starting with 1 for the root inode. It keeps a mapping for each inode that is indexed both by the inode number and by the block and block offset. The indexes are implemented using two rbtrees and protected by a reader-writer spin lock.
The patch is about 28K and can be downloaded from the following URL:
http://www.serice.net/shunt/linux-2.6.6-isofs.patch
Thanks
Paul Serice
Quoted 11 lines · Paul Serice
The ISO 9660 standard allows meta-data to be stored at almost any arbitrary byte on the file system. The current inode scheme uses the byte offset as the inode value making it easy to find the underlying block and block offset.
This scheme is subject to obvious integer overflow problems that prevents it from being able to reach meta-data beyond the 4GB boundary. Looking back through the archives, this problem was anticipated but discounted because mkisofs puts its meta-data near the beginning of the file system.
Dumb question: why not simply use a 64-bit type in the inode?
Quoted 3 lines
The patch is about 28K and can be downloaded from the following URL:
http://www.serice.net/shunt/linux-2.6.6-isofs.patch
It goes 404. Please just send the patch directly to the mailing list.
Quoted 1 line
Dumb question: why not simply use a 64-bit type in the inode?
I wasn't sure how to proceed in this direction, but I'll give it another shot.
It seems natural to use the lower 32 bits as the inode number in this case, but in general, I'm not sure what precautions I need to take when switching from a unique inode number to a non-unique inode number.
For example, at fs/isofs/inode.c:131, the comment warns that the current isofs code supports NFS implicitly because iget() works. Because I think I will have to use iget5_locked() now instead of iget(), I think I stand a good chance of breaking whatever NFS support is currently available.
Quoted 6 lines
Quoted 3 lines
The patch is about 28K and can be downloaded from the following URL:
http://www.serice.net/shunt/linux-2.6.6-isofs.patchIt goes 404. Please just send the patch directly to the mailing list.
Sorry. I didn't think my post(s) made it to the list. So, I took the patch down.
Quoted 5 lines · Paul Serice
Quoted 2 lines
Dumb question: why not simply use a 64-bit type in the inode?
I wasn't sure how to proceed in this direction, but I'll give it another shot.
The operative part of that question was "dumb". I don't know isofs, so don't go redoing things on that basis if you think the current code is the best approach.
Quoted 5 lines
Quoted 2 lines
It goes 404. Please just send the patch directly to the mailing list.
Sorry. I didn't think my post(s) made it to the list. So, I took the patch down.
The mail server was sick - please send the patch and its full description.