From owner-freebsd-geom@FreeBSD.ORG Thu Nov 15 07:47:26 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D646D16A417 for ; Thu, 15 Nov 2007 07:47:26 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 2982513C45B for ; Thu, 15 Nov 2007 07:47:26 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 4BE9C45EEB; Thu, 15 Nov 2007 08:47:18 +0100 (CET) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id BD97245E8F; Thu, 15 Nov 2007 08:47:05 +0100 (CET) Date: Thu, 15 Nov 2007 08:46:47 +0100 From: Pawel Jakub Dawidek To: Gordon Tetlow Message-ID: <20071115074647.GB80222@garage.freebsd.pl> References: <47117184.3030309@freebsd.org> <61434C70-4246-47E8-9C30-5956738B611B@tetlows.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Yylu36WmvOXNoKYn" Content-Disposition: inline In-Reply-To: <61434C70-4246-47E8-9C30-5956738B611B@tetlows.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-geom@freebsd.org, Ivan Voras , Eric Anderson Subject: Re: Disk mounting in recent Linuxes X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2007 07:47:27 -0000 --Yylu36WmvOXNoKYn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 14, 2007 at 09:27:38PM -0800, Gordon Tetlow wrote: >=20 > On Oct 13, 2007, at 6:31 PM, Eric Anderson wrote: >=20 > >Ivan Voras wrote: > >>Hi, > >>I've installed a Linux (openSUSE) on a laptop and this is what I =20 > >>got by > >>default in fstab: > >>/dev/disk/by-id/scsi-SATA_Hitachi_HTS5412_HP0400BEG1922A-part2 / > >> ext3 acl,user_xattr 1 1 > >>/dev/disk/by-id/scsi-SATA_Hitachi_HTS5412_HP0400BEG1922A-part4 /data > >> ext3 acl,user_xattr 1 2 > >>/dev/disk/by-id/scsi-SATA_Hitachi_HTS5412_HP0400BEG1922A-part3 swap > >> swap defaults 0 0 > >>A similar option (to use a device by id instead of location) also =20 > >>exists > >>for network cards. > >>(This is just a "FYI" post, I'm not complaining :) ). > > > > > >I was actually wondering if we should start labeling our filesystems =20 > >at newfs time in the installer for this type of setup. There are a =20 > >handful of potential 'gotchas' though. >=20 > The big gotcha with GEOM_VOL_FFS (I don't know if pjd@ ever addressed =20 > this when he took it over) was that GEOM was undetermined in how it =20 > handled labels that overlapped. My original thought was to use the =20 > uuid field that I allocated in the FFS superblock (AFAIK, that's still = =20 > unused). Whatever the uuid of the root device is would dictate the =20 > uuid for the system. Any volumes that didn't have the root uuid would =20 > be separated by namespace. ie /dev/vol//root if you took the =20 > root disk from another system and mounted on your system. >=20 > Of course, with the uuid moved to the filesystem, it actually gets =20 > easier in some sense (how do you figure out which labeled filesystem =20 > is your root filesystem if you have 2 labelled filesystems with the =20 > same uuid), although the loader will probably have to send it as hint =20 > to the kernel. The problem is that when you have two colliding providers (with the same name) you are already in very bad position, because no matter what you do you may end-up with system not booted properly. I decided to create first provider and warn about all others with colliding names without creating them at all. It fits into GEOM concept a bit better IMHO (you never know when the next provider with colliding name comes). All in all, the best you can do is to print a warning which demands manual intervention. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --Yylu36WmvOXNoKYn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHO/lnForvXbEpPzQRAl9NAKDKyBNDfdAdUXiIl4By0FZUyklCegCfTmjB 4j/r9zsojwpOtjIfIV/vUj8= =JXUC -----END PGP SIGNATURE----- --Yylu36WmvOXNoKYn--