On Wed, Feb 08, 2023 at 05:59:12PM +0100, Peter N. M. Hansteen wrote: > On Wed, Feb 08, 2023 at 04:50:32PM +0100, Jan Stary wrote: > > On Feb 08 13:56:18, pe...@bsdly.net wrote: > > > 1) close any open files stored there > > > 2) make sure no process has the media as $PWD (as in, cd away from there, > > > and really a variation on the first) > > > 3) issue at least one sync command (some folklore will insist on three) > > > 4) umount the media from wherever it was mounted > > > > 4 takes care of 1,2,3, right? > > It is a common assumption it does,
It certainly does the sync, from /src/sbin/umount/umount.c: int main(int argc, char *argv[]) { int all, ch, errs; /* Start disks transferring immediately. */ sync(); > but I have seen time and again applications > either coredumping and hanging while doing so or just getting terribly > confused > when their presumed current directory disappeared from under them. > > Depending on how much force you put behind the umount (as in doas, sudo) it > is not entirely certain you would be able to umount a file system that has > open files. > > Then again, your mileage may vary. And the OP asked for safe removal. I interpreted 'safe removal' as meaning that the data on the removable storage is kept intact. If a userland program crashes or mis-behaves when a device is removed, then that is really an issue specific to that program, and a somewhat different discussion. If unmounting a device, (and detaching any associated softraid device if there is one), is not enough to ensure that it's contents matches what the system believed it had written to it, then there is surely a kernel bug somewhere, (or a hardware issue).