[arch-general] Merge /bin to /usr/bin?

Kevin Chadwick ma1l1ists at yahoo.co.uk
Fri Feb 3 07:03:50 EST 2012


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.


More information about the arch-general mailing list