--VrqPEDrXMn8OVzN4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Doh, this got a little delayed.

On Sat, Oct 11, 2003 at 01:53:46PM +0930, Greg 'groggy' Lehey wrote:
> As a result of a somewhat hasty commit of fixes for Vinum, the
> question has arisen as to how to determine file system size and type.
> Currently, newfs retrieves a volume label with a DIOCGDINFO ioctl
> call.  This fails if the storage device doesn't have an associated
> partition table.

[snip]

> 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

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.

We also should run it by the other BSDs to see if they are interested in=20
this too, and/or have suggestions.

> - newfs should not require a partition table, but should attempt to
>   find one first.  If it doesn't find one, it uses defaults for block
>   and frag size, effectively unchanged from the current situation
>   where a partition doesn't contain any block or frag size
>   information.

I'd actually vote we move to this new ioctl in preference, then only look=
=20
at disklabels if it fails. I'd like this because I'd like newfs to stop=20
using struct disklabel.

a) We've been batting a "wedges" proposal around for a while. I think we
are now just to the point where we need someone to start coding. When we=20
have them in place, there won't be "disklabels" around for the kernel to=20
update. Since newfs will only ever be updating struct partition's worth of=
=20
info (in a 64-bit-clean form), we can still do the right thing with=20
wedges.

b) Even if wedges don't get here for a bit, we already have ports (macppc,=
=20
mac68k, amiga I think) that don't have struct disklabels. We synthesize=20
them now, and they don't support re-writing newfs info. If we went to a=20
just-about-this-partition method, we could more easily work updating that=
=20
info into the partitioning scheme.=20

> - In such a case, newfs should obtain the sector size from the
>   DIOCGMEDIASIZE ioctl.
>=20
> - If for any reason the DIOCGMEDIASIZE fails, the user must supply the
>   size manually.
>=20
> - newfs should not attach any special importance to the name of a
>   device without a partition table.
>=20
> I'm sure I've forgotten something here, but I think this looks
> reasonably clean.  It maintains compatibility with the existing
> partitioning scheme and allows gradual implementation of the
> DIOCGMEDIASIZE ioctl.
>=20
> Thoughts?

I think some of this has been done, but that we still need a way to push=20
partition info updates back to the kernel.

I'd say we come up w/ a good design and go with it. We don't need to be=20
too gradual. :-)

Take care,

Bill

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

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

iD8DBQE/jwD8Wz+3JHUci9cRAjj7AJ0VXG9XpgXPjyvsbyRHkPe9BdosEwCdEWJ4
MxTIMVedQPwL773V8VCr5F8=
=d3H0
-----END PGP SIGNATURE-----

--VrqPEDrXMn8OVzN4--