Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Oct 2002 11:43:29 -0800
From:      Gordon Tetlow <gordont@gnf.org>
To:        Robert Watson <rwatson@FreeBSD.ORG>
Cc:        Dan Nelson <dnelson@allantgroup.com>, Julian Elischer <julian@elischer.org>, Mark Valentine <mark@thuvia.demon.co.uk>, Poul-Henning Kamp <phk@critter.freebsd.dk>, "M. Warner Losh" <imp@bsdimp.com>, freebsd-arch@FreeBSD.ORG
Subject:   Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c
Message-ID:  <20021030194329.GZ30253@roark.gnf.org>
In-Reply-To: <Pine.NEB.3.96L.1021025154115.58150G-100000@fledge.watson.org>
References:  <20021025193859.GA51818@dan.emsphone.com> <Pine.NEB.3.96L.1021025154115.58150G-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help

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

On Fri, Oct 25, 2002 at 03:44:36PM -0400, Robert Watson wrote:
> On Fri, 25 Oct 2002, Dan Nelson wrote:
>=20
> > In the last episode (Oct 25), Julian Elischer said:
> > > <dreaming>
> > >  In the future I feel that the default names may eventually be
> > > over-ridden by semantically meaningfull names. e.g. You may partition=
 a
> > > drive and give each partition a name which might be used instead of t=
he
> > > default inherrited name.. e.g. ad0s1s2b (not a typo) may decide that =
it
> > > would rather be known "/dev/swap2" because the table entry has a field
> > > "swap%d" in it, or disk2 may decide that it wants to be known as
> > > "/dev/tunes". (A removable disk full of music)
> >=20
> > Linux allows this, sort of.  You can label disks with tune2fs, and mount
> > can find disks based either the label or filesystem UUID.  This lets you
> > have an fstab that looks like
>=20
> Gordon Tetlow and I have been discussing possibly reusing the superblock
> "last mounted on" field for volume label and uuid storage.  Right now the
> "last mounted on" data is basically used for printfs, and often somewhat
> confusingly (the kernel will print the last mount point when reporting a
> mount error, which might not be where the user is trying to mount).  It's
> 512 bytes of superblock space, so would provide lots of room for volume
> identifier information, if we decided to go that way.  Anyone interested
> in this sort of thing should spend a fair amount of time looking at prior
> art, including at Apple's approach to volume name automounting.  Also,
> Poul-Henning's comments on security are important: in some case, you may
> be less willing to trust the label on the media than others.  Another
> important consideration relates to issues like removable media, and media
> from less trusted sources, as well as accidental collisions in the
> namespace.  If anyone wants to take on this project seriously, GEOM and
> devfs provide a good starting point and many of the tools you need.=20
> Anyone giving it a try should go do a prior art search and document what
> they find, however.  :-)=20

Well, I put together the necessary struct fs patches along with the stuff
that is needed by the various utilities (newfs, tunefs, dumpfs). All this
does is put the volume label there. Nothing interesting is done with them.
The next step is to write a GEOM module that would expose those volume
labels (probably into /dev/volume). The patch is located at
http://people.freebsd.org/~gordon/patches/volume.diff  I welcome all
feedback as to code quality, it's been about 3 years since I've done
anything with C.

-gordon

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (FreeBSD)

iD8DBQE9wDZhRu2t9DV9ZfsRAh2pAJwNz58iibYn1RofD/+UhFKwjWXSVwCfTQeL
brh8qTMKLhEsmXHctckNtRE=
=00wk
-----END PGP SIGNATURE-----

--plrZyjZcS71xjaqX--

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021030194329.GZ30253>