Subject: Re: newfs: determining file system parameters
To: Ted Unangst <tedu@zeitbombe.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 10/17/2003 14:36:00
--TB36FDmn/VVEgNH/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 17, 2003 at 03:50:45PM -0400, Ted Unangst wrote:
> On Thu, 16 Oct 2003, Bill Studenmund wrote:
>=20
> > You missed the point. :-) The point is to make it so that _all_ the inf=
o,
> > 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.
>=20
> one possible concern is that this approach is very ffs-centric.

How so? i.e. who has this as a concern?

block, fragment, and cpg/sps are things newfs will read/update in the
disklabel now. newfs has to figure out which partition to update, which=20
has implications with LVMs (like vinum's issues with it).

The purpose of the ioctl is so that newfs and all the other file system=20
generators don't have to bother with a disklabel. They just know they have=
=20
a partition, and get/set info about it.

Also, ffs isn't the only file system that uses this info. lfs does too,=20
thus the cpg =3D=3D sgs value usage.

Finally, later in the note (in the bit you didn't include), I also=20
mentioned that file system type should be one of the parameters. _Every_=20
file system creation tool should pay attention to that, and be able to=20
update it when it creates a new file system.

> an ioctl for size makes sense, it is likely to be different for each=20
> partition.  block size is less likely to be tweaked by partition, and you=
=20
> can easily set a sane default in newfs.  the size is the only thing you=
=20
> need to know that can't be guessed or calculated.

Think about wedges. In a wedges-based world, we just have partitions. This=
=20
ioctl will be perfect for that. Adding it now makes it easier to go to a=20
wedges scenario.

> i think sticking the size in stat makes sense, unless there's some=20
> reason why not.  and once you can just stat the file, the ioctl becomes=
=20
> redundant.

Since there's more to all of this than just size, the ioctl has use. It in=
=20
fact is needed in the long run. :-)

Take care,

Bill

--TB36FDmn/VVEgNH/
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE/kGDAWz+3JHUci9cRAnktAJ9D8vA59KM0vEyYwSRZn+NXSCNoggCfWO62
YdLr8Lp5fips7/9kt8/9e1M=
=ISbS
-----END PGP SIGNATURE-----

--TB36FDmn/VVEgNH/--