Date: Sun, 22 Apr 2012 11:23:05 +0200 From: "Thomas Schmitt" <scdbackup@gmx.net> To: freebsd-hackers@freebsd.org Cc: wojtek@wojtek.tensor.gdynia.pl Subject: Re: what's wrong with cd9660 fs Message-ID: <99345376512413@192.168.2.69> In-Reply-To: <alpine.BSF.2.00.1204220105510.6348@wojtek.tensor.gdynia.pl> References: <alpine.BSF.2.00.1204220105510.6348@wojtek.tensor.gdynia.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
> for now i add -udf when using mkisofs and mount_udf reads fine. anyway i
> would be happy to see fully working ISO filesystem,
I am not a FreeBSD hacker but just lurking here for the topics of ISO 9660
and SCSI command transport to DVD burners. So i lack the knowledge to
develop a patch. Nevertheless i am trying to understand how FreeBSD
interprets the filesystem images which are produced by my software too.
Meanwhile i learned that the UDF implementation in fs/udf does not
provide a straightforward example for a multi-extent implementation in
fs/cd9600.
The udf vnodes have a 1:1 relation to ECMA-167 File Entries which have
a 1:N relation to ECMA-167 Allocation Descriptors which describe the
extents.
For ISO 9660 one would need to submit multiple ECMA-119 Directory Records
to the creator of a vnode. The directory records are stored in a continuous
sequence in the image. A bit in their Flags field indicates whether there is
another directory record of the same file following.
In FreeBSD this would be a set of struct iso_directory_record. Only the
fields iso_directory_record.extent, iso_directory_record.size, and
iso_directory_record.flags are supposed to vary within the set.
Bit 7 of iso_directory_record.flags is 1 if another record with the next
extent of the same file follows. (ECMA-119 9.1.6 File Flags)
struct iso_node would need to store the set of .extent and .size values
instead of its components iso_node.iso_extent and iso_node.i_size.
Then one could let cd9660_bmap() iterate over the set of extents like
it is done by udf_bmap_internal().
The vnode is created in cd9660_vget_internal(), which gets called
in cd9660_vfsops.c and in cd9660_lookup.c.
The occasions in cd9660_vfsops.c submit directories and thus are not
prone to multi-extent (ECMA-119 6.3 "Each directory shall be recorded
as a file in a single Extent").
So the place to read multiple iso_directory_record before calling
cd9660_vget_internal() seems to be in cd9660_lookup():
/*
* Check for a name match.
*/
Well, here i got stopped for now by my lack of FreeBSD knowledge.
> ISO filesystem, which is nearly optimal for read only usage.
It has a few limitations. E.g. images cannot have more than 8 TiB size.
But together with Rock Ridge it makes a fine backup filesystem, and even
the most future-ish optical media plans to not yet reach the size limit.
Have a nice day :)
Thomas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99345376512413>