From owner-freebsd-geom@FreeBSD.ORG Sun Aug 8 20:08:20 2010 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 D393E106564A; Sun, 8 Aug 2010 20:08:20 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 479B68FC1F; Sun, 8 Aug 2010 20:08:19 +0000 (UTC) Received: by qwg5 with SMTP id 5so5535847qwg.13 for ; Sun, 08 Aug 2010 13:08:19 -0700 (PDT) Received: by 10.229.214.13 with SMTP id gy13mr6441640qcb.155.1281298099105; Sun, 08 Aug 2010 13:08:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.219.17 with HTTP; Sun, 8 Aug 2010 13:07:59 -0700 (PDT) In-Reply-To: References: <20100808103055.GA2037@garage.freebsd.pl> From: =?UTF-8?Q?Marius_N=C3=BCnnerich?= Date: Sun, 8 Aug 2010 22:07:59 +0200 Message-ID: To: Ivan Voras Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: glabel "force sectorsize" patch 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: Sun, 08 Aug 2010 20:08:20 -0000 On Sun, Aug 8, 2010 at 21:08, Ivan Voras wrote: > On 8.8.2010 14:57, Marius N=C3=BCnnerich wrote: >> On Sun, Aug 8, 2010 at 14:02, Ivan Voras wrote: > >>>>> This mechanism is a band-aid until there's a better way of dealing >>>>> with 4k drives. > >> I do not like this at all. Even if it's just for the KISS and POLA >> principles. A geom should do one thing and do it right imo. > > As the addition will not modify general behaviour of glabel but add a > new feature (which is actually clean and trivial to implement) invisible > to most of the users, I don't think either KISS nor POLA are in any > danger here. "Adding a new feature" maps directly to KISS, especially if the feature is in the wrong module. POLA: I wouldn't guess that a blocksize resizing is hidden in a _part_ of glabel. I am not using the native glabel part at all, just the named GPT partitions as most of the users seem to prefer nower days (and I guess will get even more traction after Dan's blog post). > I do agree that it shouldn't be glabel's job to do this but also am > *very* strongly against shipping 9.0 without any support for 4k drives, > and the way I've chosen is the lesser of two evils. I am against workarounds for stupid hardware vendors most of the time. Especially if it's just a minority, they break pola intentionally and is fixed easily without this kludge. Afaik if you align your Partitions to higher values (I use 1MB for example) ufs is not having any performance issues (I have not benchmarked this myself). > Code and patches by others are of course welcome. I'm hoping this > discussion will trigger someone with experience in the lower levels of > kernel to go and finally add the drive info parsing so it gets solved > the right way :) > >> Why not write a new geom class that does what you want? > > I'm not against this approach also. Technically, if we go this way, the > new GEOM class will be almost a line-for-line copy-paste of glabel with > this single metadata field added, so I'd rather fold it into glabel. I did not think of a new GEOM class that looks like glabel but one that has no metadata stored on disk . It is then activated and controlled by loader.conf variables. (Maybe like gnop? If I remember correctly, I did not take a look at that class for ages). This way you would get: - Your feature - no KISS violation, that class should be really simple - no POLA violation, feature is in a class with a discriptive name, glabel is left alone - no metadata store problem (is it in the last 512 or 4K bytes?) - No problem with future compatibilty, a user would have to active the class and it's configuration by hand, no magic here Marius