> > The problem is that the detach event can be caught only too late to
> > unmount the device properly.  How may it be possible to sync a disk
> > ``as soon as it is detached'' (that is when it is not physically
> > connected to the computer anymore)?  Mounting the disk read-only may
> > be a workaround, just as not caching writes (default behaviour of
> > some versions of Windows) and syncing the disk all the time, but
> > this is not as reliable as the mount system provided by Unix and
> > Unix like operating systems.
> > 
> > AFAICR, this is the sole weakness of the FreeBSD operating system I
> > know :)  And since it is, according to me, an operator error, the
> > best we can do is to use the system as it was designed for ;)
> 
> Off the top of my head, what is wrong/hard with just logging a device
> failure, discarding all remaining cached operations, and unmounting
> the fs when a disk device goes missing? I understand that this is not
> a viable solution for critical filesystems, but I can see nothing
> wrong with this approach for removable devices and/or non-critical
> fs's.

I was wondering that myself. The possibility of losing data (after
some timeout, of course) sure as heck beats recovering from the
annoying panicks when something happens with the filesystem's
underlying device.

And who said those panicks are no problem for production systems? My
workstation is a "production system", and it is very hard to recover
from reboots in general, and crashes in particular. Unfortunately, they
do happen fairly often, usually caused by USB-related stuff (FreeBSD's
USB stack is _the_ worst I've seen lately -- I take it that the stack's
favorite hobby is panicking the kernel with unrivaled efficiency),
sometimes by ATA/ATAPI/SATA (interestingly, SCSI code is quite stable),
someimes by something obscure (e.g., just exiting qbittorrent kills the
kernel -- NFS woes maybe? just an example). Hot-swapping with some ATA
and SCSI drivers is impossible, too (result in panics).

I hope you don't mind me, an ol' whiner here, too much, but I really
had to say that FreeBSD used to be far more stable. So it seems the
trade-off "stability->features" could not be avoided...

> Comment: Nikos Ntarmos <[EMAIL PROTECTED]>

[SorAlx]  ridin' VS1400
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to