From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 19:40:38 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B4CB16A540; Mon, 26 Jun 2006 19:40:38 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7005A441B1; Mon, 26 Jun 2006 18:46:25 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 094471703F; Mon, 26 Jun 2006 18:46:22 +0000 (UTC) To: Pawel Jakub Dawidek From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 26 Jun 2006 19:10:35 +0200." <20060626171035.GE12511@garage.freebsd.pl> Date: Mon, 26 Jun 2006 18:46:19 +0000 Message-ID: <56651.1151347579@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: John-Mark Gurney , freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 19:40:38 -0000 In message <20060626171035.GE12511@garage.freebsd.pl>, Pawel Jakub Dawidek writ es: >> If you look at how everybody else (Veritas etc) does this, they reduce >> the size of the filesystem by the number of sectors they steal. > >File systems are not the whole world. MBR or BSDlabel or GPT can store >provider's size in the metadata, so when ad0, ad0s1 and ad0s1 starts at >the same physical offset, it knows which one to choose. Belive me or not >it is a real PITA. I will readily admit that we are suffering from legacy mistakes in this area, both the in-band BSD label and the "Dangerously Dedicated" mode were grave mistakes. They probably looked like good ideas at the time, but they weren't. (Think very carefully about the lesson here before you introduce new shortcuts). Other products I've worked with know how to modify the labels as necessary. The Veritas procedure to mirror the root is one of the most scary scripts I've ever run, but it worked perfectly every time, or gave up doing no damage. Yes, writing code like that is hard, takes time, takes lots of testing, but that is what it takes to deliver a quality product. >> If they can't adjust the filesystem size (either because the sector >> is occupied or because they don't recognize the filesystem) they >> refuse, leaving it up to the system administrator to solve the problem. > >Then, administrator has to dump all data to some external storage, >repartition the disks, create file systems from the begining and restore >the data. Very user-friendly. In my experience it only happens when the filesystem type is not recognized, and at least for Veritas, using the '-f(orce)' option made it proceeed. >> In this context I see your serial number proposal as a very poor >> substitute for a sensible solution because: >> >> 1. It doubles the size of the GEOM mesh by creating an alias >> for all disk devices at the bottom of the mesh. > >Is that a problem? Are there any limitations in GEOM? >And remember, glabel is optional. Yes, that is a problem, not because of the size in absolute numbers, but because they all refer to the same underlying devices. Imagine the rush during open/close/taste time. >> 2. It doesn't provide a solution for gmirror or any other class. > >Who said it will? I did. Solving the harder problem adequately would also give you solution for g_mirror, whereas just doing the quick&dirty hack would give us bugwards compatibility issues for the next N years, even if somebody more inclined to solve problems right subsequently does the right thing. >> 3. It adds a whole slew of issues with respect converting freeform >> serial numbers pathnames (What about serial numbers with hebrew >> letters in them ?) > >Heh... It doesn't seem to be a problem for >UFS/NTFS/ReiserFS/Ext2FS/MSDOSFS labels. Wanna bet ? Does g_label even bother to reject label names which contains '/' ? >> 4. It prevents cold-state swapout of disk drives. > >Why? Because /etc/fstab contains the serial number of the disk you just junked and the new one has a different serial number. >> 5. Not all diskdrives can be supported, some don't have serial >> numbers you can read (USB-sticks seems particular bad). > >Sure. And this is the reason we can't do it for those who have? Yes, I rather think so. >> The right solution seems to be to work on grow(ufs)fs so that it >> can reliably steal the last sector from a filesystem. > >Are you going to implement it? That's not an argument, Poul-Henning. >Quite everything can be refused using "the ideal solution will be..." >argument. No I will not. I do suspect however, that after a lot of pointless discussions, you will end up implementing it this way, because I am surely going to put as many roadblocks in front of your hackish scheme as I can. >> Finally, I am not against giving meaningful access to VPD[1] for disks, >> but I think we should have a unified subsystem for that, as all sorts >> of other hardware also have VPD data that would be relevant. > >Again. Let's say I've time to work on such functionality for disks only. Then you should not even begin to touch it. If you can't do it in an architecturally sensible fashion, we are better of if you don't do it. >Please try harder and be constructive. I am trying very hard to be constructive here, but you are so defensive of your own half-baked scheme that you are not even considering the proposals I make. >Let me provide few examples. Should we backout GEOM, because it doesn't >support mediasize changing, [...] There is a big difference between something which is architecturally sound but incomplete and something which is an architectural mess. We don't back out the former, we complete them, and hopefully everybody had learned by now to not even commit the latter in the first place. Let me give you two relevant examples to think about: 1. A new journaled filesystem which initially does not support subdirectories, FIFOs and symlinks. 2. A hare-brained hack to add journaling to an existing mission critical (for FreeBSD) filesystem by means of layering violations and quick hacks. Yes, we commit the former, hoping it will grow to completion. No, we don't commit the latter because it will be a maintenance nightmare from day 1. >I'm not saying we should accepts all hacks proposed, but I'm not trying >to design a hack here. I beg to differ: You are. >This is why I brought this to arch@. You only brought it to arch@ because I asked you to, and the reason I asked you to, was to get this discussion into the archives where it belongs. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.