On Fri, Jan 12, 2018 at 6:39 AM, Mick <michaelkintz...@gmail.com> wrote:
> On Friday, 12 January 2018 09:58:17 GMT Adam Carter wrote:
>>
>> Pretty sure you'd risk filesystem corruption by not umounting before you
>> remove the device. Did it used for force an fsck on each mount because the
>> filesystem was "dirty"? If not, i have a fundamental misunderstanding of
>> how this stuff works.
>
> Yes, the sequence ought to be:
>
> sync && umount /dev/<device> || eject /dev/<device>
>
> I don't recall if eject includes the previous steps and therefore it is
> superfluous.
>

Actually, all but umount are superfluous for a USB device.

umount already ensures that all writes are written to disk - the
system call does not return until the disk is completely settled.  All
a sync would do is force all your other filesystems to also flush
their write caches, which could cause performance issues and
potentially make it take longer to flush the drive you actually want
to remove.  There is no need to run eject on a USB drive - just pull
the thing and udev will clean up the device nodes.  For other busses
like SATA there might be benefits to deleting the device before hot
swapping them, but I'm not sure if eject actually works on those.

If you umount the device, and wait for the command to terminate, then
you're fine removing it.

This is all somewhat orthogonal to your original question though -
these are all things that you ought to do before you remove the
device, not after.

One thing I tend to do with scripts for backups to external devices
that I don't intend to leave mounted is build the mount and umount
into the backup script itself.  I usually also include a check to
ensure that some file/directory exists which I expect to be on the
drive, which prevents the backup script from dumping a full backup
into your mountpoint if it isn't mounted (possibly on a filesystem
with insufficient space - actually, making /mnt a tmpfs with a tiny
RAM allotment might make sense for just this reason).  If you're
running your backups in a service this could also be stuff that goes
into the service config (esp with systemd you can make a mount a
pre-req and have it automatically unmounted on termination whether
successful or not; you could probably script the same sort of thing
with openrc, but there is less benefit there since you don't have
things like timer units to trigger them and they're not
containerized/etc).

-- 
Rich

Reply via email to