New option for newfs(3) to make life with GEOM easier

Gergely CZUCZY phoemix at harmless.hu
Sat Sep 1 03:00:38 PDT 2007


On Sat, Sep 01, 2007 at 01:23:10PM +0400, Yar Tikhiy wrote:
> On Sat, Sep 01, 2007 at 08:13:07AM +0000, Poul-Henning Kamp wrote:
> > In message <20070901074803.GM85633 at comp.chem.msu.su>, Yar Tikhiy writes:
> > >Hi all,
> > >
> > >With some geom(4) modules saving their metadata in the last sectors
> > >of block devices such as disks and partitions, 
> > 
> > 1.  If those geom modules do not reduce their providers to prevent
> > this metadata from being overwritten, they are buggy.
> 
> In some scenarios, it can be desirable to newfs first, geom later.
True, done it many time myself. Since sysinstall doesn't allow you
to install onto a gmirror array, many install via sysinstall, and gmirror
the system afterwards, which is exactly this situation.

> 
> > 2.  Why not simply allow the -s argument to newfs to be negative so
> >     "-s -200" means "reserve 200 sectors" ?
> 
> A negative argument to -s has been invalid till now, so we propose
> a new option for people to express their intentions explicitly.
> Personally, I don't mind the "-s -200" syntax, but many people
> consider overloaded arguments unintuitive and error-prone.
I think this "-s <negative>" syntax is just fine. As far as
the manual will mention this, there's no problem with it.
Introducing a new exclusive option could result in people
trying to use both at the same time :)

Though for this, geom class manuals should mention how much
space do they need for the metadata at the end. Or to simplify
thing an option for like "reserve some space for (gmirror|gstripe|gfoobar)"
should be introduced. Or specifing the module and newfs could "ask"
the geom class for its metadata size that should be reserved.
Just thinking, sorry if it was too wild...

Sincerely,

Gergely Czuczy
mailto: gergely.czuczy at harmless.hu

-- 
Weenies test. Geniuses solve problems that arise.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 1812 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20070901/5b10b2ec/attachment.pgp


More information about the freebsd-fs mailing list