On Tue, 31 Jan 2012 17:40:48 +0000 Kevin Chadwick wrote: > > E.g. who is making sure the disk is unmounted before it > > is unplugged > > (yanking it out whilst mounting/fsck'ing does not sound like a good idea btw)? > > Yeah, I found this out, of course nothing is psychic and can prepare > for that but you do normally get a safely remove option (I haven't > mainly because I couldn't be bothered to dig any deeper into udev. It seems mounting to /media rather than /mnt that my OpenBSD users are used to (I'll create links) means you get the safely remove option. > It > would be easier to create just that part from scratch, I think). I am > using flush etc. but haven't fully tested it on all the filesystem > types I may use yet. I do prefer it showing me how long it takes to > copy rather than saying it's done ages before it has like on my > standard udev boxes. It may even be that users are more likely to yank > out prematurely (bar completed) with the standard setup atleast the > first time with the corrupt or missing file teaching them to get an OK > first. Okay so it worked, however using sync is extremely slow and for ntfs-3g uses a rediculous amount of cpu, now I think I recall a document saying you nee a particular filesystem to run qmail well on Linux (with sync for highly reliable Maildir). I guess I'll just have to make sure my users use safely remove. I believe there is a major issue which is hidden by usb-2.0 as it copies so fast but may affect some slow micro sds, which is a small file looks like it is copied immediately. On OpenBSD it does buffer but also flushes very often so that the user knows when it is actually completed, though the copy rate drops to 0 every so often. I guess it just reduces the window but works brilliantly. It's not just about premature removal it's also annoying when you stop what your doing thinking a hrd drive has finished only to find it's still emptying the cache.
