Re: [gentoo-user] How to set udev rule?

[Jesús Guerrero]

On Sun, August 30, 2009 23:26, Alex Schuster wrote:
> Jesús Guerrero writes:
>
>
>> Then they wonder why the heck
>> the file is not where it should be. I guess they never heard of cached
>> writes.
>>
>> The correct thing to do is of course to umount it before,
>> and then unplug it or whatever.
>
> I do so, it makes me feel better, but I wonder whether it is _really_
> necessary.

It is. Nothing can guarantee that the data has been dumped to the disk
unless you umount it first. You can reduce the chances of losing
information by waiting before removing it. But if the system is loaded
the writes can be deferred to a later time, when the system is idle.
This can be partially mitigated by using the "sync" mount option, as
you say below. :)

Of course then the performance will drop, and the i/o scheduler will
not have a chance to work as usual either because i/o ops will not be
queued, which is the bad part of the deal.


> I see Windows users do this all the time, without any problem
> yet. Of course, the wait a little after writing to it, but a few seconds
> after the blinking stops seem to be enough.

Lucky guys. That, or when the file is not on the drive they come back
and copy it again without you noticing it. This happens lots of times.
I've seen it and I'll continue to see it as long as users don't
understand what's going under the hood. That's what the safe removal
feature in Windows is about, it's not there just to decorate your
try, it exists for a reason.

> And people are lazy,

Yes, I am as well. But when integrity matters you really want to umount
or at least sync before unplugging. I am a lazy guy, lazy like hell, but
I always fasten my seat belt when I am going to drive. ;)

> The
> udev mouting rule is nice, but it leaves a lot of mounts when plugging in
> and out repeatedly.

Mmmm, I am not sure I follow you. If you use a rule as described above
you can remove the mount and even the mount point when the device is
detached. Is not that what you mean?

> When the system is mostly idle, I guess the writing to the stick would
> not be delayed for a long time, so this should be quite safe. At least if
> the data is not that important. And if there are no writes, I see no
> problem at all.

If you don't have a problem with the chance to lose files that's ok. I
just thought I'd point it out just in case, because the chance is there.
A write operation can be deferred for a number of reasons. That's why
"sync" (both as a command and as a mount option) was invented in first
place.

> There also is the sync option to mount, it should not be used on media
> with limited number of write cycles, but I also guess that for my purposes
> this would not matter.

Nowadays this shouldn't matter too much. The life cycle of ssd devices
has been greatly expanded, and they also do some kind of balancing so
all the blocks get the same usage. Even journal fs's shouldn't be much
of a problem with any recent flash device.

-- 
Jesús Guerrero