Subject: Re: newfs: determining file system parameters
To: David Laight <david@l8s.co.uk>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 10/16/2003 17:55:02
--tNQTSEo8WG/FKZ8E
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 17, 2003 at 12:20:32AM +0100, David Laight wrote:
> > > In addition to these parameters, newfs interprets the last letter of
> > > the device name as a partition identifier.  This can fail badly if a
> > > device has a name like 'baz'.
> > >=20
> > > I'd suggest that the following method would solve the "problem":
> > >=20
> > > - implement an ioctl DIOCGMEDIASIZE to return the size of a special
> > >   device. =20
> >=20
> > I'd like to change your suggestion some. I think this new ioctl should=
=20
> > return _all_ the info newfs needs. It should contain all the info in=20
> > struct partition, and enough other info (like device sector size) from =
the=20
> > disklabel.
>=20
> Actually it is easy, and mostly done.
>=20
> All newfs needs from the disklabel is the partition size and sector size.
> The size always has been available via fstat for open block devices [1],
> a minor change to spec_open has made it available for open character
> disk devices (which newfs uses by default).
> A simple check that the partition number generated from the name matches
> that from the minor device number also sanities the selection of the
> partition in the label.
>=20
> Nothing extra is required.

You missed the point. :-) The point is to make it so that _all_ the info,
including saved block, fragment, and cpg value, are obtainable without=20
needing a disklabel. And also so that they can be updated w/o needing a=20
disklabel.

No struct disklabel. :-)

You've made a lot of changes, which I think are good. But these changes=20
don't address the ability to update data concerning FS type and=20
parameters. We should be able to (in principle) update the FS info for any=
=20
partition, and to do that, we have to move away from disklabels. If they=20
have the space, even Vinum and RAIDframe units should be able to store=20
this info, though I'm not sure if they can.

Take care,

Bill

--tNQTSEo8WG/FKZ8E
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE/jz3mWz+3JHUci9cRAs/hAKCKIo0WVENDAT7QqD8lKMNUwhhuzwCeNAqC
pSnqCAQ6n6vArjLmxmu3O8Q=
=Hf9Z
-----END PGP SIGNATURE-----

--tNQTSEo8WG/FKZ8E--