From owner-freebsd-current@FreeBSD.ORG Sun Nov 30 10:59:07 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED3EF1065677 for ; Sun, 30 Nov 2008 10:59:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 911008FC0A for ; Sun, 30 Nov 2008 10:59:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1L6k12-000Nfj-Aw; Sun, 30 Nov 2008 12:59:04 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id mAUAwxJq004476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Nov 2008 12:58:59 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id mAUAwxo0026277; Sun, 30 Nov 2008 12:58:59 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id mAUAwxq6026276; Sun, 30 Nov 2008 12:58:59 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 30 Nov 2008 12:58:59 +0200 From: Kostik Belousov To: Luigi Rizzo Message-ID: <20081130105859.GF3045@deviant.kiev.zoral.com.ua> References: <20081130043110.GA48062@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lIrNkN/7tmsD/ALM" Content-Disposition: inline In-Reply-To: <20081130043110.GA48062@onelab2.iet.unipi.it> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1L6k12-000Nfj-Aw 892f57104c51b741ac65e5e5f09e8ffd X-Terabit: YES Cc: current@freebsd.org Subject: Re: libufs limitation trying to make newfs work on plain files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2008 10:59:07 -0000 --lIrNkN/7tmsD/ALM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 30, 2008 at 05:31:10AM +0100, Luigi Rizzo wrote: > libufs limitation trying to make newfs work on plain files >=20 > Hi, > I have been trying to modify newfs so that it could work on plain > files (the overall goal being to have more flexible tools to > manipulate filesystem images without the special privileges needed > by mdconfig). >=20 > Unfortunately, it seems that this cannot be done without modifying > the 'struct uufsd' in libufs.h so that it can deal with an offset in > the file (see below for a detailed description). >=20 > As far as I can tell libufs is only used by a small number of programs: > /sbin/badsect: > /sbin/dumpfs: > /sbin/ffsinfo: > /sbin/newfs: > /sbin/tunefs: > /usr/sbin/snapinfo: >=20 > so i don't think the change will create a major trouble in=20 > an upgrade. So, are there any objections if I work on such a > change planning to add it also in RELENG_7 once 7.1 is out ? >=20 > DETAILS > The problem i want to solve is make newfs able to create a partition > at an arbitrary offset in a file, so that we can create a disk image > without having to glue together the various filesystem and slice > in a second pass, and without requiring root privs to run mdconfig > or the like. >=20 > But right now newfs expects to open the actual partition (e.g. > /dev/da0s1f) and thus the partition data start at offset 0 within > the file descriptor. This assumption is in turn propagated down to=20 > libufs. >=20 > If you operate on a file representing the entire ufs slice, the > various partitions start at offsets !=3D0 (even worse, if the file > represent an entire disk image, the slice itself would be at a > non-zero offset). So you need to pass the offset to the start of =20 > the filesystem (in the general case an off_t) to the I/O routines > in libufs, and this information should be stored in the 'struct > uufsd'. >=20 > In principle one could use some tricks and describe the offset > with a few unused bits in the 'd_mine' field in struct uufsd: > + 1 bit to signal that we are operating on a plain file so > the filesystem does not start at offset 0; > + 3 bits to indicate which partition we are using (a..h) > + 1 bit to indicate that the slice is within a disk image > + 2 bits to indicate which entry in the MBR describes the slice. >=20 > With this info the code could possibly locate the slice offset > within the image file, read the disklabel from there, then > add the offset of the partition within the slice, and without > needing to change the structure. >=20 > But clearly this is not as clean as adding an extra field to the > structure. Adding field to the structure is the most clean approach, but we do need to make some supportive changes to keep our users happy, esp. when the plan is to merge the change to the stable branch. You proposal would introduce incompatibility in the ABI exposed by one of the system library. The solution adopted by Linux and (recently) by FreeBSD, is to use ELF symbol versioning. It seems that this case can be handled by symver. As additional benefit, after your work we would got one more symver-ed system library. --lIrNkN/7tmsD/ALM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkkycfIACgkQC3+MBN1Mb4guugCg4wehdKZrk63SoEK3t/O1HY5D 6wMAnRp4uq1aTk20jwv6XVlntjOoJvUR =W5kb -----END PGP SIGNATURE----- --lIrNkN/7tmsD/ALM--