what's wrong with cd9660 fs

[Thomas Schmitt]

Hi,

> mkisofs -rJ --iso-level 3 -o /path_to/file.iso .
> and i see TWO 4 gigabyte files with the same name!

This happens too on my "8.0-STABLE Mar 23 14:55:20 CET 2010".
FreeBSD is probably not alone with this.

An example image can be found at
  https://dev.haiku-os.org/attachment/ticket/8473/file_of_4gb.iso.bz2
compressed 25 KiB bzip2, uncompressed 4.1 GiB ISO 9660 image with
"file_of_4gb" having 2 extents.

The content of the image root directory should be:

$ ls f*
-rw-r--r--  1 1000  1000  4297064448 Apr 16 13:00 file_of_4gb

But on FreeBSD i get this:

$ bunzip2 file_of_4gb.iso.bz2
# su
Password:
# mdconfig -a -t vnode -f file_of_4gb.iso
md1
# mount_cd9660 /dev/md1 /mnt
# ls -l /mnt/f*
-rw-r--r--  1 1000  1000  4294965248 Apr 16 13:00 file_of_4gb
-rw-r--r--  1 1000  1000  4294965248 Apr 16 13:00 file_of_4gb

Omitting Rock Ridge interpretation changes the result:

# umount /mnt
# mount_cd9660 -r /dev/md1 /mnt
# ls -l /mnt/f*
-r-xr-xr-x  1 root  wheel  2099200 Apr 16 13:00 file_of_4gb


This is a skewed reflection of the image entrails:
The file content is stored in two file sections (see also ECMA-119 6.5.1).
The directory records of both sections bear the same File Identifier
(struct iso_directory_record.name), but different Location of Extent
(struct iso_directory_record.extent) and Data Length
(struct iso_directory_record.size).
One extent begins at block 55 (= .extent) and has 4294965248 bytes (= .size).
The other begins at block 2097206 and has 2099200 bytes.

Afaics in my local copy of
  /usr/src/sys/fs/cd9660/cd9660_node.h
there is a 1:1 relation between struct iso_node and ECMA-119 extents:
        long iso_extent;        /* extent of file */
        unsigned long i_size;
In
  /usr/src/sys/fs/cd9660/cd9660_vfsops.c
i believe to see a 1:1 relation between struct vnode and struct iso_node:
        vp->v_data = ip;
        ip->i_vnode = vp;

But there would be needed a 1:N relation between inode and ECMA-119 extents
in order to represent large files.

I am currently trying to understand how fs/udf handles multiple extents.
  /usr/src/sys/fs/udf/udf_vnops.c
bears in function udf_bmap_internal() a comment:
                 * If the offset is beyond the current extent, look for the
                 * next extent.


Have a nice day :)

Thomas