Subject: Re: newfs: determining file system parameters
To: Bill Studenmund <wrstuden@netbsd.org>
From: Christian Limpach <chris@pin.lu>
List: tech-kern
Date: 10/21/2003 02:08:40
On Mon, 20 Oct 2003 15:34:51 -0700 Bill Studenmund <wrstuden@netbsd.org> wrote:

> > but then we should also wait with adding any ioctl until we have a real
> > need for one ;-)
> 
> And what makes you think we don't now?

the fact that I can't read your mind ;-)  no seriously, the discussion
emerged from the Vinum/newfs/-V change and _that_ doesn't need an ioctl
_now_.

If you have changes which need an ioctl now, then the ioctl using struct
partition is the most reasonable solution we can have now.

> No! newfs and everthing else just talks to the kernel. If the
> partitioning scheme is something the kernel can re-write (or technically
> update), then it rewrites the disklabel. In a wedges world, it passes the
> request down to the wedge daemon.

So how does newfs for a filesystem which needs more than 64 bits to store
its filesystem specific data get this data into the on disk partition meta
data storage?

> The problem with a library that all tools use is that all the tools have 
> to grow as new partitioing schemes come into play. While we could do
> that, I think it'd be easier (looking towards wedges) to have newfs and
> friends tell the kernel what to do. For now the kernel does what it can,
> but in  the future, it talks to the wedge daemon (which will want to know
> this anyway).

No, the tools don't have to grow because the library would have an API
which is independent of the partitioning scheme.  I think a library for
this would be really nice, it would get/put part of the information
from/into the kernel and the rest to the wedge daemon.  Or put all of it
through the kernel, or put all of it through the wedge daemon, whatever
works best.  The major advantage would be that the tools don't need to be
aware of what is stored where.

> > Also, if the store in the kernel is minimal, then filesystem specific data
> > shouldn't be stored in it.  On the other hand, some kind of filesystem
> > identifier (name or some kind of UUID) should probably be stored in the
> > kernel...
> 
> File system data represent 64 bits (8 bytes) per partition. I think a
> minimal store can deal with that. If it were much more I'd agree we might
> not want it in the kernel anymore. Also, the hassle of getting it from 
> somewhere else will most likely be more hassle than 8 bytes per
> partition are worth. :-)

That's all true.  However I didn't mean that the filesystem specific data
shouldn't be stored in the minimal in-kernel store because of the 8 bytes
it takes but because we should try to get this right and legacy free.
This doesn't provide for filesystems where 64 bits isn't enough and that
we'd want a design where a facility is available for some filesystems and
not for others is surprising ;-)

-- 
Christian Limpach <chris@pin.lu>