Subject: Re: newfs: determining file system parameters
To: Christian Limpach <chris@pin.lu>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 10/20/2003 22:46:32
--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 21, 2003 at 02:08:40AM +0200, Christian Limpach wrote:
> On Mon, 20 Oct 2003 15:34:51 -0700 Bill Studenmund <wrstuden@netbsd.org> =
wrote:
>=20
> > > but then we should also wait with adding any ioctl until we have a re=
al
> > > need for one ;-)
> >=20
> > And what makes you think we don't now?

Sorry, that really should have had a :-) on it. :-)

> 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_.

Sorry, I had mentioned it earlier in my postings, though I admit it may=20
have disapeared in the noise.

> If you have changes which need an ioctl now, then the ioctl using struct
> partition is the most reasonable solution we can have now.
>=20
> > 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 t=
he
> > request down to the wedge daemon.
>=20
> 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?

I'm not really sure.

The flip side of the question though is how would we store that extra data=
=20
in different metadata stores? I want to expand the Apple partition map to=
=20
hold what we store in a partition now. I bet we can expand the other=20
methods to hold frag/block/cpg if they don't already hold it.

Though holding more than that, I'm not sure how we can do it.

However, what file system needs that info? Won't any such file system be=20
constrained to partitioning schemes that can hold that info now?

I agree that such a file system would not work so well with this ioctl,=20
but I think we should wait for such a file system to know what to add. :-)

> > The problem with a library that all tools use is that all the tools hav=
e=20
> > 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 kn=
ow
> > this anyway).
>=20
> 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.

Oh, my though was that the tools would only perform the set version of the=
=20
ioctl on the partition. The exact routing to disk writes or wedge daemon=20
calls would be up to the kernel.

The other thing I like about the newfs(and friends) -> kernel -> wedged=20
approach is that we can limit the privilege needed for newfs - the newfs=20
(or friend) process doesn't need to be able to write disklabels, only the=
=20
kernel or wedged need to.

> > 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 mig=
ht
> > not want it in the kernel anymore. Also, the hassle of getting it from=
=20
> > somewhere else will most likely be more hassle than 8 bytes per
> > partition are worth. :-)
>=20
> 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 ;-)

As above, we'll have a lot of trouble getting more than these 64 bits into=
=20
most partition stores. :-)

Since I really don't know what (if any) other file system will need, I=20
don't see how we can design such a facility now. :-)

Take care,

Bill

--YiEDa0DAkWCtVeE4
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQE/lMg4Wz+3JHUci9cRAkREAJ9q8WX+WnIj1YxMoLKrB2IjwHPBewCeLzfV
gf4Ogv+ptfgSKKYzfCvS2jE=
=ArFx
-----END PGP SIGNATURE-----

--YiEDa0DAkWCtVeE4--