1

When working from command line I usually use an USB mass storage device with customary:

sudo mount /dev/sde1 /mnt -o rw,umask=0000
... use it...
sudo umount /mnt

This works fine IF you let the stick in its slot a few seconds AFTER umount has terminated (and shell prompt is back).

Having a stick equipped with activity LED I can clearly see there's activity for a sizable amount of time AFTER umount (there's ample time to reach for the stick and yank it away AFTER prompt returns, but BEFORE it goes quiet).

Waiting for activity to terminate ensures filesystem on stick is not corrupted.

I suspect Device driver is still working.

Question is: Which command (if any) could ensure device can be removed as soon as prompt returns?

Note: eject does not work (for this).

ZioByte
  • 830
  • 1
  • 10
  • 22
  • Could someone be so kind to explain why I got downvoted? – ZioByte Sep 15 '19 at 15:01
  • Is the LED the only indication you have or is there actually a case of data corruption when pulling it? You could also try `echo 1 > /proc/sys/vm/block_dump` and watch dmesg when umounting. – frostschutz Sep 15 '19 at 15:39
  • 2
    `eject /dev/sde` (on the whole device, not `sde1`) does work and will unmount any mounted partitions of it. Try it with `strace -e trace=umount,umount2 eject /dev/sde`. –  Sep 15 '19 at 16:38
  • @frostschutz: I had real corruption, as testified by `fsck`. I will try the `block_dump' trick. Thanks. – ZioByte Sep 15 '19 at 16:49
  • 1
    @mosvy: I was actually using `eject /dev/sde1`. Using the whole device it seems to work as expected (at least I didn't have corruption in the few tries I did). If You reformat Your comment into an Answer I will accept it. – ZioByte Sep 15 '19 at 17:32
  • `eject /dev/sdX` (on the whole device X) is recommended. Additional comment: It will work also with `sudo umóunt /dev/sdX?` to unmount all partitions (1,2 ... 9) if existing, and the drive will still be alive (possible to 'see' and mount again). I have used this umount command thousands of times without causing corruption, when the drive is unplugged. – sudodus Sep 15 '19 at 19:41
  • @sudodus: `sudo umóunt /dev/sdX#` returns as soon as buffers are flushed to Device Driver; DD still buffers a lot of `struct bio` (sometime thousands) and can take a few seconds to process them all. At least this is my understanding. – ZioByte Sep 16 '19 at 16:04
  • @ZioByte, Interesting, this is new information for me. I have used that `umount` command successfully (without corruption), but what you say means that it is potentially risky. Please explain `struct bio` or link to an explanation. – sudodus Sep 16 '19 at 18:39
  • @sudodus: You can have a look [here](https://linux-kernel-labs.github.io/master/labs/block_device_drivers.html) or [here](https://www.oreilly.com/library/view/linux-device-drivers/0596005903/ch16.html) for details, but my understanding is Block Devices prepare a chain of `struct bio` whenever they must write something and that is forwarded between various driver layers (filesystem, VFS, raid, ...) till they get to the Device Driver actually responsible for writing to HW (possibly through DMA). Read requests use reverse path. Lowest level usually deal with a single bio structure. – ZioByte Sep 16 '19 at 19:16
  • @ZioByte, Those links are far deeper than I have dived into this subject :-o But flushing buffers *should* be finished by `sync` and `umount` runs `sync` before it does the unmounting. I have thought that LED indication of activity could also show "the drive's internal management" of rearranging the connections between logical memory addresses and memory cells to spread the wear (avoid that a few memory cells get worn out). And that activity should be run so that unplugging (which turns off the power supply) will not cause corruption. – sudodus Sep 16 '19 at 19:55

0 Answers0