Re: FreeBSD 7 trivial problems / notes
--nextPart1772793.P2GptbU4c5
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Wednesday 12 December 2007 20:50:56 Ivan Voras wrote:
> 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).
If you mean the "errors=3Dcontinue / errors=3Dremount-ro / errors=3Dpanic"
option in Linux then it's define the behavior of the system when the=20
filesystem is found to be in non consistent state, but not whether fsck is=
=20
able to check it or not. So it's somewhat diffrent. Personally i do not=20
see the requirements for this option too.=20
Also there is a knob in defaults/rc.conf called "netfs_types" may be it=20
could be used to skip network filesystem checking?
>
> > % 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 :-)
> >
> > 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
> them) - 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.
=2D-=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20
=2D Best regards, Nikolay Pavlov. <<<----------------------------------- =
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20
--nextPart1772793.P2GptbU4c5
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQBHYSsO/2R6KvEYGaIRAkcyAJ0YUWkljGre+QlCFurda1hWo5l8dQCeKU14
nKIzA0PfEjDdfoUXNmTJihI=
=P4CU
-----END PGP SIGNATURE-----
--nextPart1772793.P2GptbU4c5--
討論串 (同標題文章)
完整討論串 (本文為第 10 之 10 篇)：