Re: FreeBSD 7 trivial problems / notes

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={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=ignore 0 0
>
> Perhaps you mean "fsckerror=ignore"?
> 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=continue / errors=remount-ro / errors=panic"
option in Linux then it's define the behavior of the system when the 
filesystem is found to be in non consistent state, but not whether fsck is 
able to check it or not. So it's somewhat diffrent. Personally i do not 
see the requirements for this option too. 

Also there is a knob in defaults/rc.conf called "netfs_types" may be it 
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.



-- 
======================================================================  
- Best regards, Nikolay Pavlov. <<<-----------------------------------    
======================================================================