rsmith at xs4all.nl
Fri Dec 23 23:21:36 UTC 2011
On Sat, Dec 24, 2011 at 08:03:22AM +1000, Da Rock wrote:
> > If the network goes down, network drives won't work. Your users will be
> > sad/scared/frustrated with or without error messages, I'm guessing.
> Nah. They'd flip out a whole lot more when the screen literally fills
> with error messages and keeps going. Frustrated they can handle and
> maybe complain, but that would make them run away... :)
Wouldn't you get some error message or other if a network drive becomes
unreachable no matter what?
> > Another way to go about it is to install e.g. ubuntu on a virtual machine and
> > peek under the hood how it works there. But as you say it's probably tied into
> > udev pretty tightly.
> Tried that too, but each distro has there own "hack" to make it work for
> them. Crazy huh?
I tried ubuntu once in a VM (I was a slackware user before moving to
FreeBSD). Had a quick look with ps and was rather appalled at all the stuff
that was running with no obvious way to turn it off.
> > Devd just gets some notifications and acts on them. There is a problem with
> > mounted usb devices, but that is one of architecture, I guess. Devd only gets
> > notified _after_ a device has been pulled. There is no way you can prevent
> > data loss in all cases like that. On windows you're supposed to "prepare to
> > eject" a USB device before pulling it out as well. The only "cure" is to mount
> > a device syncronously, and disable _all_ write caching for those devices. If
> > you try that you'll find that doing so has significant performance impact and
> > not in a good way (disks are sloooow).
> Almost need a "journaling" system for them. Any thoughts? What about
> setting up a temp folder (non-volatile buffer?) and a sync? Track
> devices using the uuid label?
With proper mount settings and synchronous writes you might be able to prevent
most damage, but it'll be slow. The default for mount is to write metadata
syncronously, while data I/O is done async, see mount(8). No matter what you
do, if a user pulls a USB stick during a write, the filesystem on it will be
left in an inconsistent state. Nothing you can do about that.
FreeBSD be default already does buffering in the VFS layer (unless you turn
that off). I don't think that adding more buffering would help. It might even
make matters worse. If data is buffered and not immediately written to the USB
stick, it will show no activity. This might even give the user a false
impression it is finished...
Basically if a USB drive is plugged back in again, you have to accept the
state that it is in at that time. You cannot assume that it's state is still
the same or even related as the last time it was plugged in. But suppose for
the sake of the argument that you have a complete and correct copy of the USB
stick's filesystem at the time it was pulled buffered. Now assume the same
device is plugged in again. You read the complete state of the filesystem and
compare it to your buffer. Suppose there is a difference between the two. What
are you going to do? Without further information there is no way of knowing
which of the changes are OK because they were done e.g. on another computer.
And there is the application that is writing that is to be considered. With
buffering enabled, write system calls return as soon as the metadata is
written and the data is queued, IIRC. So as fas as the app is concerned, it is
done. Of course the next system call to write to the same fs after it is
pulled will get an error. But that still leaves the application's image of the
file's state different from reality.
The only sane way to handle this is for the application to get an error from
the next write reporting that the filesystem has disappeared. Which it should
then report to the user because that's the person that pulled the plug, so to
> > submit it to the freebsd-doc mailing list for inclusion in the official docs?
> I may yet do that, but in the interim I'm going to get around to writing
> up my findings on a lot of different aspects of the systems in a wiki
> (I'll put up my findings on those as well...). Maybe my pain can help
> someone else :)
Please but up a link to that wiki. :-)
> For reference _all_ my systems are FreeBSD: from laptops/desktops,
> HTPC's and servers. I'd like to be able to show a system better and more
> robust than the alternatives out there as well as easy on the users, and
> thats what I'm always working towards.
Nice! I wish I was able to use FreeBSD at work (other than on my own laptop).
> > And talking about mailing lists, maybe you should try your luck on the
> > freebsd-gnome list?
> > [http://lists.freebsd.org/mailman/listinfo/freebsd-gnome]
> I would but I'm not subscribed to that one (must be about the only one
> I'm not on :) ), and it hadn't come to mind as I wasn't using gnome! I'm
> using nautilus for testing as it has more features, but I'm intending on
> using pcmanfm or similar- lightweight, but usable.
All the mayor players in this drama, hal, policykit and dbus are maintained by
gnome at . In practice that _might_ mean that no single person cares enough to
care and feed them.
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20111223/2bd33d6a/attachment.pgp
More information about the freebsd-questions