Re: [PATCH] isofs meta-data beyond 4GB

[Sergey Vlasov <vsu@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]

On Thu, May 20, 2004 at 09:26:12AM -0500, Paul Serice wrote:
<skip/>
> 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 number and
> block offset.  The indexes are implemented using two rbtrees and
> are protected by a reader-writer spin lock.

Why use a spinlock here?  The filesystem code is always called in a
process context, therefore a semaphore is much more appropriate than a
spinlock.  BTW, your code allocates memory with SLAB_KERNEL while
holding a spinlock, which is wrong; the check for allocation failure
is also missing.

Also there are other, more serious problems with your approach:

- The inode map can consume a lot of memory, which is never released
  until unmount.  Someone could prepare a disk full of zero-length
  files and run "find" on it to crash the machine.

- Inode numbers for the same disk become not stable across mounts (can
  be annoying if automounters are used).

However, the 4GB limit problem really needs to be solved.  Here is
another idea (sorry, no patch yet): instead of the byte offset of the
directory entry, use its sector number and index in the sector.
isofs_read_inode() then would need to read the sector and skip the
specified number of directory entries to find the needed one.

The minimum possible size of an ISO9660 directory entry is 34 bytes
(33 bytes for struct iso_directory_record, 1 byte for file name).
Therefore there cannot be more than 60 directory entries in a single
CD-ROM sector (2048 bytes), so the number of a directory entry in the
sector can fit into 6 bits.  With 32-bit inode numbers this leaves 26
bits for the sector number, which is enough for up to 128GB.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]