From owner-freebsd-questions@FreeBSD.ORG Mon Mar 21 10:41:22 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC5F3106566C for ; Mon, 21 Mar 2011 10:41:22 +0000 (UTC) (envelope-from max@mxcrypt.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 835A28FC13 for ; Mon, 21 Mar 2011 10:41:22 +0000 (UTC) Received: by vws18 with SMTP id 18so5728448vws.13 for ; Mon, 21 Mar 2011 03:41:21 -0700 (PDT) Received: by 10.220.178.200 with SMTP id bn8mr1016472vcb.194.1300704081373; Mon, 21 Mar 2011 03:41:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.68.9 with HTTP; Mon, 21 Mar 2011 03:40:51 -0700 (PDT) In-Reply-To: <87k4ftp01o.fsf@oak.localnet> References: <87k4ftp01o.fsf@oak.localnet> From: Maxim Khitrov Date: Mon, 21 Mar 2011 06:40:51 -0400 Message-ID: To: freebsd-questions@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Carl Johnson Subject: Re: glabel causes "GEOM: ada1: media size does not match label" messages X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 10:41:22 -0000 On Mon, Mar 21, 2011 at 12:30 AM, Carl Johnson wrote: > Maxim Khitrov writes: > >> On Sun, Mar 20, 2011 at 4:38 PM, Maxim Khitrov wrote: >>> Hi all, >>> >>> Executing the following commands on any valid storage device seems to >>> cause "media size does not match label" kernel messages (FreeBSD 8.2 >>> amd64). I understand why they happen - glabel metadata occupies the >>> last sector, so bsdlabel sees a device that is 1 sector smaller than >>> what the kernel sees. The question is whether there is some simple way >>> of suppressing these messages, since they come up every time the >>> system is booted or the partition is mounted/unmounted: >>> >>> # glabel label vol0 ada1 >>> # bsdlabel -w /dev/label/vol0 >>> GEOM: ada1: media size does not match label. >>> # newfs /dev/label/vol0a >>> # mount /dev/label/vol0a /mnt >>> GEOM: ada1: media size does not match label. >>> # umount /mnt >>> GEOM: ada1: media size does not match label. >>> >>> As you can see, I'm not using MBR or GPT partitioning schemes. I try >>> to avoid those unless I plan on sharing the media with another OS. >>> Even if using gpart would get rid of these errors (not sure, since >>> then you'll just have a partition whose size doesn't match), I would >>> still prefer to find some other way to suppress them. >>> >>> - Max > > =C2=A0I am not an expert, but that looks correct as you have it, so I wou= ld > expect some other problem. =C2=A0You are using vol0 as the partition for > newfs and its size should be correctly sized to allow for the last > sector of ada1 being used by glabel. =C2=A0I have heard comments that the= re > problems in what some call 'dangerously dedicated' partitions, so you > might want to create a single slice covering the whole disk and > partition that. I've been using 'dangerously dedicated' partitioning for years without any issues. What problems have been reported by others? > =C2=A0If you just want volume names for a filesystem, you might want to t= ry > the -L option for either newfs or tunefs. =C2=A0The last example of the > glabel manpage shows using a ufs label to contrast it with glabel. =C2=A0= I > use ufs labels for all of my filesystems and just use glabel for swap, > and I suspect that swapon wouldn't catch the type of problem that you > are seeing. I do use UFS labels where necessary. In this case, I'm writing a script that needs to access all bsdlabel partitions through a common name. >> Heh... In the process of searching for a solution to this, I decided >> to see what would happen if I used bsdlabel on ada1 rather than vol0 >> (in my example above), and created a 1-sector partition at the very >> end of the disk. So the layout would be something like this: >> >> # /dev/ada1: >> 8 partitions: >> # =C2=A0 =C2=A0 =C2=A0 =C2=A0size =C2=A0 offset =C2=A0 =C2=A0fstype =C2= =A0 [fsize bsize bps/cpg] >> =C2=A0 a: =C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2= =A0 =C2=A04.2BSD >> =C2=A0 c: =C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2= =A0 =C2=A0unused >> =C2=A0 h: =C2=A0 =C2=A0 =C2=A0 =C2=A01 =C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2= =A0 =C2=A0unused >> >> The 'c' partition now covers the entire disk, which stops the kernel >> from complaining about media size not matching the label. At the same >> time, the 'h' partition will protect the last sector, which contains >> glabel metadata. >> >> The problem now is that the label is technically invalid for the vol0 >> device, which is what I'll be mounting. Indeed, bsdlabel complains >> when I run it for /dev/label/vol0: >> >> # /dev/label/vol0: >> 8 partitions: >> # =C2=A0 =C2=A0 =C2=A0 =C2=A0size =C2=A0 offset =C2=A0 =C2=A0fstype =C2= =A0 [fsize bsize bps/cpg] >> =C2=A0 a: 3907029151 =C2=A0 =C2=A0 =C2=A0 16 =C2=A0 =C2=A04.2BSD =C2=A0 = =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 0 >> =C2=A0 c: 3907029168 =C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0unused = =C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 0 >> =C2=A0 h: =C2=A0 =C2=A0 =C2=A0 =C2=A01 3907029167 =C2=A0 =C2=A0unused = =C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 0 >> partition c: partition extends past end of unit >> bsdlabel: partition c doesn't cover the whole unit! >> bsdlabel: An incorrect partition c may cause problems for standard >> system utilities >> partition h: partition extends past end of unit >> >> I don't care about partition 'h'; it is there only to stop the >> preceding partition from covering the last sector. Are there any real >> issues with the 'c' partition being 1 sector too big for the vol0 >> device (but just the right size for ada1)? >> >> This is a bit of a hack, but I'll take it if it stops the kernel from >> complaining and doesn't create any new problems. > > I don't see where adding an extra partition at the end does anything to > protect the earlier partition. In my example, if I remove the 'h' partition, "a: * * 4.2BSD" will be sized to take-up the entire disk, including the sector containing glabel metadata. This would allow newfs/UFS to overwrite that sector with some other data. By adding an extra 1-sector partition at the end, I'm making sure that the metadata stays outside of 'a' or any other partition preceding 'h'. This is only necessary when allowing bsdlabel to pick partition sizes automatically (using '*' for size). Once bsdlabel is written, the 'h' partition can be deleted. It will simply show up as 1-sector free space at the end of ada1. - Max