Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 03 Apr 2007 08:37:58 +1000
From:      Antony Mawer <fbsd-fs@mawer.org>
To:        Pawel Jakub Dawidek <pjd@FreeBSD.org>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: gjournal error
Message-ID:  <461185C6.3040801@mawer.org>
In-Reply-To: <20070402161220.GA34180@garage.freebsd.pl>
References:  <b37cb0970703300454l75eae76dyc75c1be5e31f65@mail.gmail.com>	<20070330181015.GB11360@garage.freebsd.pl>	<b37cb0970704020235vf3171f0g8227002607972342@mail.gmail.com> <20070402161220.GA34180@garage.freebsd.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
On 3/04/2007 2:12 AM, Pawel Jakub Dawidek wrote:
> On Mon, Apr 02, 2007 at 12:35:10PM +0300, Dan Cojocar wrote:
...
>> Here it is:
>> bsdlabel /dev/ad1s1
>>                                                        12:32:40
>> # /dev/ad1s1:
>> 8 partitions:
>> #        size   offset    fstype   [fsize bsize bps/cpg]
>>  c: 234440625        0    unused        0     0         # "raw" part,
>> don't edit
>>  d: 20971520        0    4.2BSD     2048 16384 28552
>>  e: 213469105 20971520    4.2BSD     2048 16384 28552
> 
> 'd' partition is wrong, it should start at offset 16. You get EPERM
> (error=1) when someone tries to write to first 16 sectors where metadata
> is stored.

This point relates to a recent thread on -questions, where we were 
discussing the offset of 16 and whether it was still relevant. The issue 
arose because disklabel cannot compute the "hog partition" when using an 
offset of 16 -- it (incorrectly) assumes the starting offset is is 0, 
and as a result the last partition goes past the end of the disk.

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1660728+0+archive/2007/freebsd-questions/20070401.freebsd-questions

What sort of meta-data is typically stored in these first 16 sectors? Is 
it only of concern if you are using some of the various GEOM modules 
that require meta data storage?

It sounds to me like disklabel needs to be modified in how it treats a 
"*" in the size field: on the 'c' partition, continue to use the full 
size of the device; if used on any others, it needs to take into account 
the offset of the first non-'c' partition...

Does this sound right? If so, I may have a go at writing a patch at some 
point.

--Antony



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?461185C6.3040801>