From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 22 09:22:28 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43E87106566B for ; Sun, 22 Apr 2012 09:22:28 +0000 (UTC) (envelope-from scdbackup@gmx.net) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id AB08F8FC14 for ; Sun, 22 Apr 2012 09:22:27 +0000 (UTC) Received: (qmail invoked by alias); 22 Apr 2012 09:22:19 -0000 Received: from 165.126.46.212.adsl.ncore.de (HELO 192.168.2.69) [212.46.126.165] by mail.gmx.net (mp072) with SMTP; 22 Apr 2012 11:22:19 +0200 X-Authenticated: #2145628 X-Provags-ID: V01U2FsdGVkX1/E9UYKZrzEcfHUAjKyhNo+p2Eu0TVJyvw9tjcTvt yY9fPhZd6KavFV Date: Sun, 22 Apr 2012 11:23:05 +0200 From: "Thomas Schmitt" To: freebsd-hackers@freebsd.org References: In-Reply-To: Message-Id: <99345376512413@192.168.2.69> X-Y-GMX-Trusted: 0 Cc: wojtek@wojtek.tensor.gdynia.pl Subject: Re: what's wrong with cd9660 fs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 09:22:28 -0000 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