Date: Fri, 26 Oct 2012 10:46:35 -0700 From: Jeremy Chadwick <jdc@koitsu.org> To: Polytropon <freebsd@edvax.de> Cc: freebsd-questions@freebsd.org, schmidt@ze.tum.de Subject: Re: ata controller problem Message-ID: <20121026174635.GA33092@icarus.home.lan> In-Reply-To: <20121026184328.c1e849f2.freebsd@edvax.de> References: <20121026163338.GA32286@icarus.home.lan> <20121026184328.c1e849f2.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 26, 2012 at 06:43:28PM +0200, Polytropon wrote: > > I wish people would stop recommending this utter garbage. There is > > absolutely no justification behind using the highly convoluted labelling > > mechanisms at multiple layers within FreeBSD. There are 3 (possibly 4) > > different "label" mechanisms which do nothing but confuse the user, or > > cause other oddities/complexities. Good grief, there is so much hard > > evidence on the mailing lists over the past 5 (maybe even 7?) years > > talking about the utter mess that is filesystem/device/geom/blahblah > > labels that to recommend this is borderline insane. > > Yes, the amount of different, present (in parallel) and > differently implemented and accessible labeling mechanisms > can be confusing. There is no "the one true way" to do it. > Especially when dealing with metadata (e. g. for rare cases > of data recovery) it might make things more complicated. > > I don't agree that labels in general "do nothing but confuse > the user" - the same could be said about controllers, devices > and how they are partitioned (again, many different ways here). > But users usually don't deal with that. Sysadmins do. And they > should be able to deal with it, as it's not _that_ complicated > (from their educated and experienced point of view, I assume). > > That's why I would still say labels have their place, especially > in settings with many disks (10 and more) where concluding > "which disk?" is sometimes required, in terms of disk, not > disk _bay_. Let me make myself extra clear here -- and I won't be replying past this point (privately or publicly): What the OP wanted was to have a static mapping between a physical SATA port (e.g. Card #1 Port #0) and a device name (e.g. ada0) -- one which never changes no matter if there's a disk attached to the port or not. The wire-down method described above does this. Using labels does not. Here's a list of the wonderful fun things labels offer: - You get to remember or write down the label; don't forget it - You get to change /etc/fstab - You get to pray you never have to replace a disk, and if you do, that you remember which labelling method you used, and/or deal with partitioning complexities (see last item) - You get to be subjected to bugs in the GEOM layer or UFS layer when it comes to labels (this has happened!) - If using GPT (the only present way to align a partition properly to a 1MByte boundary -- matters greatly for SSDs due to NAND erase page size!), you're subjected to the problem where GEOM stores its metadata in the last sector, which is also where GPT stores its backup table. This is even documented in the Handbook, which is both good *and* hilarious at the same time And don't forget about the automatic vs. manual GEOM label method (but for this case I'm assuming automatic is used, since that method stores metadata). Every one of these situations has happened to at least one person in the past 5 (7?) years. They CONTINUE to happen. It cannot be denied. We FreeBSD users way too often shove our fingers into our ears and yell "LALALA" when people point out shortcomings. Blind advocacy of any kind of technology these days is something to be wary of. All that said: labels have a very, very specific purpose, backed by a list of many caveats. But "I want to ensure controller port X maps to device X at all times" is not one of those purposes. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | 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?20121026174635.GA33092>