Date: Wed, 27 Apr 2011 01:42:18 -0400 From: "Jason J. Hellenthal" <jhell@DataIX.net> To: Doug Barton <dougb@freebsd.org> Cc: freebsd-fs@freebsd.org, Alexander Motin <mav@freebsd.org>, Alexander Best <arundel@freebsd.org> Subject: Re: Why not just name the cam-ata devices the same as the old names? Message-ID: <20110427054218.GA88420@DataIX.net> In-Reply-To: <4DB759A1.4050201@FreeBSD.org> References: <4DB70949.6090104@FreeBSD.org> <20110426182017.GA92471@freebsd.org> <4DB70F13.6060002@FreeBSD.org> <BANLkTikFHLaQ=Vrt9UhyJdo5ELm522OZjA@mail.gmail.com> <4DB759A1.4050201@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 26, 2011 at 04:47:45PM -0700, Doug Barton wrote: >On 04/26/2011 16:04, Mikael Fridh wrote: >> Are labels such a perilous affair that you can't just start >> recommending them and/or default to them? > >As far as I can tell, yes. We have various different tools that do=20 >different things, all calling themselves "labels" which don't all work=20 >together well. It's also unclear how many (if any) of those solutions=20 >will survive the file system being newfs'ed. > >I made this point elsewhere, but this is an area where linux really has=20 >us beat. At install time a UUID is created for a file system if it=20 >doesn't already have one and it's referred to that way in fstab. My=20 >understanding (although I have yet to test it) is that they survive=20 >newfs because they are not located on the fs itself. When I first saw=20 >this I thought it was ugly (read, different) but having worked with it a= =20 >little bit I think it's a much superior method, and would have made the=20 >current concerns completely irrelevant.=20 >http://www.linux.com/archive/feature/146951 > Hi Doug, I do not know if this was summed up in a easy way by Jeremy's nice message below but in short a summary can be made here to clear that up. /dev/gptid/* /dev/gpt/* * These survive its raw partition being newfs'd * Are only created for disks that are partitioned and contain a GPT table as can be seen with gpart show * Operations on these or the raw partition will not remove them. /dev/ufsid/* /dev/ufs/* * Will not survive a newfs * Are created upon being newfs'd * /dev/ufs/* is the equiv of (tunefs -L) * /dev/ufsid/* is only created by newfs(8) * Operations on these or the raw slice will not remove them. /dev/label/* * Are created by glabel(8) * Will remain with the disk until its raw disk is newfs'd or data overwrites the metadata on the raw disk. * When created only the label should be newfs'd directly as a new on the disk itself would overwrite the metadata stored. * Operations on the label itself is only supported to retain the metadata. =09 The best possible thing you could use here is a GPT scheme for the disks to remain consistent across newfs's. But relying on GPT for all disks will not always work in situations where the disk also involves a operating system that does not support booting off of a GPT disk, like all of Windows XP and then Win7 for non-Itanium based architectures. Yes Win7 last checked was said to only support booting GPT schemes on Itanium systems, so this leaves a lot of systems to only rely on /dev/ufs*/ labels or generic labels. --=20 Regards, (jhell) Jason Hellenthal --KsGdsel6WgEHnImy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNt6y5AAoJEJBXh4mJ2FR+oKAH/05PIBZ2f4QMu5Byb/l0MK7l VR0bjcbwUQg+bYnqDPKwIfUCwo/kfiVYOnlFkAiMA5EBKlR9K/P2XYUHa3edE/ss 2AuO/aOjBqv/TOpVN/N9XsB8zHexu5A5/rZxN1FRSTiK/oKLanhmc69UO5tJqUxm PIEzTunKF4GhG8jBj83q8GFyPLhWiegArTuKgaYs2XgWYAH+5SWVYk1OFfLNxfcz kYM/mHDOlzzASm4axiXa7I+iGFRvoy5W7hNry/aAm4wMu8GOL+gtSkA17O8THEuT R9gugndpnvrL2rinaZyr+QPf1R60EwxNO9FVkEpRkJmPQEefVb4XDE/anoWCV4M= =BqRe -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110427054218.GA88420>