Date: Wed, 12 Dec 2007 19:50:56 +0100 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-current@freebsd.org Cc: freebsd-doc@freebsd.org Subject: Re: FreeBSD 7 trivial problems / notes Message-ID: <fjpaio$uri$1@ger.gmane.org> In-Reply-To: <20071211205813.GB1455@kobe.laptop> References: <fjho0k$hdc$1@ger.gmane.org> <20071209234943.GB2112@kobe.laptop> <9bbcef730712091554p63d4ec54sdaf0abcb6e5b1c65@mail.gmail.com> <20071210225421.GA28116@keltia.freenix.fr> <20071211205813.GB1455@kobe.laptop>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigAFD02F3760159A8DDB6B7D75
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Giorgos Keramidas wrote:
> % The suggestion to make it non-fatal sounds nice though. Maybe
> % we should consider an `rc.conf' option which controls if mount
> % failures are actually considered fatal or just `annoying', and
> % then make the failure conditional on that option, i.e.:
> %
> % mount_failure_level=3D{IGNORE,WARN,FATAL}
I like this, but will like to suggest that "WARN" or "IGNORE" be the
default, since I think there's practically no chance of backward
compatibility issues.
> % Adding a mount(8) option, which can be set per filesystem is
> % probably also a good idea, i.e. something like:
> %
> % /dev/acd0 /cdrom cd9660 ro,auto,mounterror=3Dignore 0 0
Perhaps you mean "fsckerror=3Dignore"?
IIRC Linux has something like this (the "mounterror" variant), and in
some way it's nice to have this fine-grained per-file system, but this
particular instance won't save the user from having a machine
non-bootable with file systems that don't have fsck (if you already know
you need to ignore this type of error, you already know that you need
"2" in the fsck field).
> % It's too late to introduce something like this to 7.0, but if
> % it works and is accepted as an idea, we can implement it on
> % HEAD and backport it later :-)
>=20
> I still don't see why user-error in fstab for tmpfs should be
> treated as a special case, but that's probably me being blinded
Making tmpfs a special case for stab would certainly be a bad idea :) I
was always suggesting generic solutions.
> by a few years of "UNIX can let you shoot your foot, but it's not
> the fault of UNIX if you do, in fact, blast it off".
I appreciate the charm and the wisdom of the "old-school" way of
thinking, but you will recognize that, in additions to many good things,
it has brought us some not so good, among which are:
- kernel panics on file system corruption (instead of just unmounting the=
m)
- kernel panics when mounted devices go missing, e.g. USB (instead of
just umounting it)
- "root is god" model which everyone except the embedded people are
trying hard to replace nowadays (ok, this one's hard to solve)
- "kern_map too small" panics in ZFS (anything's better than panics; why
isn't it delaying requests in low memory conditions?)
- ...probably more; this subject pops up every now and then on the lists.=
Modern systems should fail gracefully - Unix thrived on small systems
with limited resources which maybe couldn't afford this policy, but
current systems can do better.
--------------enigAFD02F3760159A8DDB6B7D75
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.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHYC2XldnAQVacBcgRAmU1AJ45Y903C+dVxSmcoAttZN5LNVNqIQCdHu/K
uU53a8eIp1gAYLFe16WLU4Q=
=Ff3G
-----END PGP SIGNATURE-----
--------------enigAFD02F3760159A8DDB6B7D75--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fjpaio$uri$1>