From owner-freebsd-hackers@FreeBSD.ORG Sun May 18 18:16:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 108E2D35 for ; Sun, 18 May 2014 18:16:14 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 89B642F48 for ; Sun, 18 May 2014 18:16:13 +0000 (UTC) Received: from scdbackup.webframe.org ([87.167.175.94]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lug8u-1WueDa2ct6-00zpS3 for ; Sun, 18 May 2014 20:16:10 +0200 Date: Sun, 18 May 2014 20:15:45 +0200 From: "Thomas Schmitt" To: freebsd-hackers@freebsd.org Subject: About a bug in cd9660 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20420668849133366718@scdbackup.webframe.org> X-Provags-ID: V03:K0:rIYyef9n5PFcRYptv+PCQ5lIhuhCR6cpz5A8o4ctpKNFkH0nBAQ HSWF2i3ZzSNc4wGUEACkUttf29EItAUXungG9YgHl/QqWzAYBDYqlda7DnEP89tx2BkzRsn XUXmHRUg5HFcVLIvnhg4FQdiYNLGIEHYrOneOVcIGMDmdn4rc2NjqCT4IY5QUKNBwdeeLfu lR5c4kXuz2m+yhHyrrXOA== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 18:16:14 -0000 Hi, two years ago, i reported a cd9660 problem with multi-session ISO 9660 where the last session begins above 4 GiB. http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038570.html This bug is fixed now in NetBSD http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=48787 The problem was a 32 bit rollover of the inode number. This number is simply the byte address of the ISO 9660 directory record, which caused the existence of the inode. The inode number is used to access this byte address for resolution of symbolic links, and for accessing directories. NetBSD has 64 bit ino_t. So adding a cast operator to the generation of the inode number fixed the problem. By webinterface i believe to see it in current FreeBSD source, too. The rollover in function isodirino(): http://fxr.watson.org/fxr/source/fs/cd9660/cd9660_node.c?v=FREEBSD10#L319 The reverse computation of the directory block address http://fxr.watson.org/fxr/source/fs/cd9660/cd9660_vfsops.c?v=FREEBSD10#L773 The reverse computation of the byte address of the directory record of a symbolic link target http://fxr.watson.org/fxr/source/fs/cd9660/cd9660_vnops.c?v=FREEBSD10#L692 And the reason why the NetBSD remedy will not help FreeBSD http://fxr.watson.org/fxr/source/sys/_types.h?v=FREEBSD10;im=3#L46 At least on my olde FreeBSD-8.4, sizeof(ino_t) is really 4. For the purpose of directory addressing, the problem could be postponed up to a limit of 128 GiB by dividing the byte address by 32 (or 34 if one wants to squeeze out the record size guarantee of ISO 9660). See (meanwhile retracted) proposal http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=48797 But the task of symbolic link resolution will need to be implemented without relying on the inode number. I am willing to help fixing this problem in FreeBSD, but am currently still busy with learning how to interface with NetBSD kernel and (very friendly) community. There is another problem to be solved. Files larger than 4 GiB show identical symptoms as on FreeBSD: http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038552.html So additionally to my knowledge about ISO 9660 and my half-knowledge about cd9660 filesystem code, there would be the need for somebody who knows how to properly implement what will be determined to be necessary. Actually i believe the existence of 32 bit ino_t leaves FreeBSD no choice but to get rid of the ino_t-to-address hacks in cd9660. Have a nice day :) Thomas