On Sat, Dec 24, 2011 at 10:44:53PM +1000, Da Rock wrote: > > And yes, that will block write calls until they're truely done. > You said that was slower too.
A bit. But I think it is a good trade-off for filesystems on USB disks. It certainly circumvents a whole lot of problems with filesystem consistency and stuff. > All valid points. What it boils down to is if you yank the power or the > disk during write you're screwed no matter what fancy tricks you play- > include hal/dbus/blah! bull crap. Yep. :-) > You have tickled my imaginationings again, and I have an idea to throw > at the gurus on the list (including you Roland): Assuming null/void > computer literacy, and the use of a DE; what if one had an (can't be a > script can it - pointless. Thinking on the fly here...) applet? dock > notifier? that indicated the disk was in use and not to remove - > primarily for a "blinkered" user that is missing the flashing led on the > drive (or one missing an led)? Stays on top, flashing on the screen. Use > mount -d to test disk status, then lets you know that it can be removed. > I still have to test this, but I thought I'd throw it out there. Just add a button to that applet that is called "eject" or "remove" (or something like that) and have that unmount the fs in question. Then put up a dialog or notification saying "The USB device can be removed" or something of that nature. That's basically what windows does, and it works well enough. > Basically, the situation (that I have found myself in numerous times) is > the write stops to the disk because the buffers need to reach a certain > level before write occurs, or umount. So one can mistakenly assume that > all is kocher and find no file when they reinsert. Files are lost that > way, and at the least its annoying. That can still even occur with hal > and blah blah blah. I'd still advocate mounting these discs with '-o sync'. Yes, it is a bit slower but it prevents a lot of trouble and is a lot easier. > Is this feasible though? If the user still can't pay attention to _all_ > of that then they're not worth worrying about- can't be holding their > hand the whole time :) Then, using devd, one can implement the > mount/umount scripts with a quick fsck on insertion to be sure ICIE (In > Case of Idiot Event). Unmounting with devd is just triage. Umount cannot do some useful things (like flushing buffers) if the disk has already been removed! It can only remove the mount so you won't get trouble when the user sticks the device back in. And on a 4 GiB thumbdrive, I doubt an fsck is going to be really quick! Remember that the drive will be basically unusable when the check is in progress. I could imagine getting all kinds of complaints from users in the shape of "I plugged it in and it doesn't work". It should not be too difficult to write a script that is called from devd when a new USB device is detected (I think you should watch for CREATE events from the CDEV subsystem of the DEVFS system). I think it should check /dev first for new disk labels (/dev/msdosfs or /dev/ufs) and second for for disk devices, and try and mount them using appropriate filesystems under /mnt/$USER/$NUM (the latter because there might be more than one USB device in use). Optionally it could also launch a new instance or new window of the user's file manager, depending on how much hand-holding and customization you want to do. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
pgpYMMD1iv2hW.pgp
Description: PGP signature
