Date: Tue, 26 Apr 2011 17:37:56 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> 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: <20110427003756.GA71905@icarus.home.lan> 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
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 > different things, all calling themselves "labels" which don't all > work together well. It's also unclear how many (if any) of those > solutions will survive the file system being newfs'ed. > > I made this point elsewhere, but this is an area where linux really > has us beat. At install time a UUID is created for a file system if > it doesn't already have one and it's referred to that way in fstab. > My understanding (although I have yet to test it) is that they > survive newfs because they are not located on the fs itself. When I > first saw this I thought it was ugly (read, different) but having > worked with it a little bit I think it's a much superior method, and > would have made the current concerns completely irrelevant. > http://www.linux.com/archive/feature/146951 I concur regarding the many different things all calling themselves labels. The most common mistake is for folks to assume glabel(8) is the same thing as newfs(8)'s -L flag. They're unrelated things. Regarding the latter, I'm under the impression FreeBSD GEOM already does exactly that (creates a UUID) -- but only when GPT is in use. The glabel(8) man page hints at this: Support for partition metadata is implemented for: o GPT labels (directory /dev/gpt/). o GPT UUIDs (directory /dev/gptid/). Folks reading the man page should also pay very, very close attention to the difference between "automatic" and "manual" labels. They matter. This topic comes up a couple times a year and tends to bite a user in the butt. The reason I don't care to use name-based labels: They all rely on metadata, which usually involves use of the last LBA on the disk (and metadata implementations vary per filesystem and OS). If the administrator forgets to zero that out before decommissioning a disk (or worse, re-using the disk in another machine), there could be a label conflict and I have no idea how that's handled internally. I'd love to assume "glabel clear" does the right thing when zeroing the metadata, but I have not confirmed this. My personal preference is to rely entirely on device names. I know exactly what physical bay /dev/ada1 correlates with. Thankfully, "camcontrol devlist -v" makes this easier for folks. There was (but no longer) some evidence that use of GPT UUIDs, at least on ZFS, may fail or surprise the user with problems. This has since been fixed, but situations like this have made me very wary: http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007895.html I also remember there being a time where UFS UUIDs were printed on console, but this made a lot of people angry (me not so much, but I was quite surprised) and I think their printing was disabled, or the functionality was turned off entirely. I'm not sure which. I'm talking about this stuff (when you see it, it will bring back memories): http://www.mail-archive.com/freebsd-questions@freebsd.org/msg218431.html <rant> GEOM is one of those things on FreeBSD which is like the rabbit hole in Alice in Wonderland. It's never as it appears on the surface; how deep the hole goes is quite amazing. For example, did you know "gpart list" works despite being undocumented? And that "geom part list" is the same command? src/sbin/geom/core contains the magic. Once you see how it's implemented (specifically: everything is "blindly" handed off to the kernel). I spent some time reading all of this code many moons ago. Yup, rabbit hole. The irony (to me anyway) is that all of the userland-centric "stuff" is actually implemented in the kernel via callbacks. When I realised this, it immediately made me think of the whole "Porting OpenBSD's sensors framework to FreeBSD" debacle ~4 years ago. Specifically this post: http://lists.freebsd.org/pipermail/freebsd-arch/2007-July/006625.html libgeom(3) should be doing all the heavy lifting, but that library has been greatly neglected and its documentation even more so. For example, sysinstall still gets its disk geometry data by parsing the hidden sysctl OIB kern.geom.conftxt (you need to use "sysctl -b" to view it). There's also kern.geom.confxml (its purpose is unknown to me). The data in both OIDs isn't available via any other means, yet the entire thing screams "userland API". I came across that tunnel in the rabbit hole when I found that use of gsched(8) flat out breaks sysinstall. There's also libdisk(3), which is used as well, yet the top of the man page states "you should probably be using libgeom(3)". Oh really? This stuff is in such a state of disarray... :-( </rant> -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110427003756.GA71905>