Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Apr 2009 14:52:45 +0200
From:      Ivan Voras <ivoras@freebsd.org>
To:        freebsd-geom@freebsd.org
Subject:   Re: geom_label verbosity patch
Message-ID:  <gspoap$gpp$1@ger.gmane.org>
In-Reply-To: <20090423123511.GB1798@mail.wheel.pl>
References:  <gspkp8$4g4$1@ger.gmane.org> <20090423120035.GA1798@mail.wheel.pl>	<gspm4e$92n$1@ger.gmane.org> <20090423123511.GB1798@mail.wheel.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3BE643728B3B9554AEA8F745
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Pawel Jakub Dawidek wrote:
> On Thu, Apr 23, 2009 at 02:15:14PM +0200, Ivan Voras wrote:
>> Pawel Jakub Dawidek wrote:
>>> On Thu, Apr 23, 2009 at 01:52:01PM +0200, Ivan Voras wrote:
>>>> Hi,
>>>>
>>>> I want to ask for a community review of these patches:
>>>>
>>>> http://people.freebsd.org/~ivoras/diffs/geom_label_errlevel.txt
>>>> http://people.freebsd.org/~ivoras/diffs/glabel.8_errlevel.txt
>>>>
>>>> The intent is to make glabel less chatty on detection of new provide=
rs,
>>>> etc. [...]
>>> This is on purpose, so don't change that. One can always set it to -1=
=2E
>> Possible, but it would make it unique among other GEOM classes.
>=20
> Almost every GEOM class informs about creating providers, so what you
> suggest is inconsistent.

I think you feel more strongly about the topic than it warrants it -
"almost every" is not "every" and glabel is technically a slicer just
like gpart - you wouldn't like gpart to announce as it creates da0s1a,
da0s1b, da0s1c, etc.? Besides, the trend is toward reducing the amount
of generic (redundant, repeatable) information on boot. :)

What could be possibly more useful is to create a framework that would
output only "diff" messages - i.e. that shows that I had da0s1a or
ufs/mylabel when I booted last time, and I suddenly lost it now. But
this is non-trivial for many reasons, including how and where to store
the information and what to do with hot-plug devices. Maybe devd could
take care of all these announcements?

>>> This way we not only make it less chatty again, but also not to pollu=
te
>>> /dev/.
>> One way to lessen it is to stop creating individual directories for ea=
ch
>> label class, as discussed before.
>=20
> How is it going to reduce number of providers in /dev/?

I was thinking about the "ls /dev" case. What other thing would be a
concern in the number of entries in what's essentially a very light
weight memory file system whose content are nodes of several bytes in
size (less than 100 bytes if I count them correctly, +vnodes, labels,
book-keeping)?


--------------enig3BE643728B3B9554AEA8F745
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ8GSdldnAQVacBcgRAneuAJ9VmkQkXpVQHj1gN890CSGjrUorgQCdGbKa
8ODJyXMGrDElMmUO4Tc3rY4=
=n85i
-----END PGP SIGNATURE-----

--------------enig3BE643728B3B9554AEA8F745--




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?gspoap$gpp$1>