| 1 |
On Fri, Jan 12, 2018 at 6:39 AM, Mick <michaelkintzios@×××××.com> wrote: |
| 2 |
> On Friday, 12 January 2018 09:58:17 GMT Adam Carter wrote: |
| 3 |
>> |
| 4 |
>> Pretty sure you'd risk filesystem corruption by not umounting before you |
| 5 |
>> remove the device. Did it used for force an fsck on each mount because the |
| 6 |
>> filesystem was "dirty"? If not, i have a fundamental misunderstanding of |
| 7 |
>> how this stuff works. |
| 8 |
> |
| 9 |
> Yes, the sequence ought to be: |
| 10 |
> |
| 11 |
> sync && umount /dev/<device> || eject /dev/<device> |
| 12 |
> |
| 13 |
> I don't recall if eject includes the previous steps and therefore it is |
| 14 |
> superfluous. |
| 15 |
> |
| 16 |
|
| 17 |
Actually, all but umount are superfluous for a USB device. |
| 18 |
|
| 19 |
umount already ensures that all writes are written to disk - the |
| 20 |
system call does not return until the disk is completely settled. All |
| 21 |
a sync would do is force all your other filesystems to also flush |
| 22 |
their write caches, which could cause performance issues and |
| 23 |
potentially make it take longer to flush the drive you actually want |
| 24 |
to remove. There is no need to run eject on a USB drive - just pull |
| 25 |
the thing and udev will clean up the device nodes. For other busses |
| 26 |
like SATA there might be benefits to deleting the device before hot |
| 27 |
swapping them, but I'm not sure if eject actually works on those. |
| 28 |
|
| 29 |
If you umount the device, and wait for the command to terminate, then |
| 30 |
you're fine removing it. |
| 31 |
|
| 32 |
This is all somewhat orthogonal to your original question though - |
| 33 |
these are all things that you ought to do before you remove the |
| 34 |
device, not after. |
| 35 |
|
| 36 |
One thing I tend to do with scripts for backups to external devices |
| 37 |
that I don't intend to leave mounted is build the mount and umount |
| 38 |
into the backup script itself. I usually also include a check to |
| 39 |
ensure that some file/directory exists which I expect to be on the |
| 40 |
drive, which prevents the backup script from dumping a full backup |
| 41 |
into your mountpoint if it isn't mounted (possibly on a filesystem |
| 42 |
with insufficient space - actually, making /mnt a tmpfs with a tiny |
| 43 |
RAM allotment might make sense for just this reason). If you're |
| 44 |
running your backups in a service this could also be stuff that goes |
| 45 |
into the service config (esp with systemd you can make a mount a |
| 46 |
pre-req and have it automatically unmounted on termination whether |
| 47 |
successful or not; you could probably script the same sort of thing |
| 48 |
with openrc, but there is less benefit there since you don't have |
| 49 |
things like timer units to trigger them and they're not |
| 50 |
containerized/etc). |
| 51 |
|
| 52 |
-- |
| 53 |
Rich |
Archives