Users of autofs for removable media expect to be able to copy files and
directly remove the media without having the need to call sync(8) or umount(8).
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential D42494
autofs: media: Always use sync option for fat* manu on Nov 7 2023, 3:41 PM. Authored by Tags None Referenced Files
Details Users of autofs for removable media expect to be able to copy files and Sponsored by: Beckhoff Automation GmbH & Co. KG
Diff Detail
Event TimelineComment Actions I’m not a huge fan of this one tbh. I seem to remember I had it like this for a while, and it was 1. Unbearably slow and 2. Increased flash wear and tear. How about decreasing the default timeout for autounmountd to eg three seconds instead? Comment Actions For 1/ yes it will be slower. But safer.
That will work if you do everything from the command line and aren't in the /media/XXX directory. But for users using graphical env like a file explorer I suspect that they will right click on the file, copy, move to the media dir, right click, paste and leave the explorer open while they remove the usb thumb stick (a la windows) so that will not help. Comment Actions From what I remember it will be _a lot_ slower for eg an SD card. And not that much safer, tbh, because it can still result in a corrupted filesystem - this just reduces the time window for this to occur. To me, it's pessimizing the common case (FreeBSD users tend to understand how to use media) as a partial workaround for... something.
I seem to remember there was a drama on LWN few years ago "Linux destroying drives" by mounting them sync by default. I don't remember the details though.
Doesn't unmount(2) syscall sync the filesystem even when it fails to unmount it due to being busy? Comment Actions FreeBSD users don't tend to understand how to use media :)
Maybe, but unmount will not be called if the user remove the drive before autounmound kicks in. Comment Actions Sync is probably the best default here given we don't have what we actually want. IMO, what we actually do want is to fairly aggressively flush dirty buffers to disk and when the disk goes idle to return the on-disk metadata to an unmounted state. Comment Actions Using this quick and dirty test script : https://dpaste.com/37CL5BKK5
+-----------------------------------------------------------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 10 27.8 77.94 49.09 52.032 14.910511 If you start the script with -x and look at the separate time for cp and umount (tbh too lazy to do another script and run that does that) you can clearly see that the time we gain without using sync for copying file we lost it in umount (well for the sync). And this is what we're interested in for autofs and removable media, we want the data to be as soon as possible on the disk so the user can remove it (or click a button that will umount the drive, and do that not in 20-30 secs). Comment Actions Thank you, I think I'm fine with toggling it from "async" to "sync" specifically for msdosfs. Also, note that simply adding "sync" to /etc/auto_master will probably break automounting cd9660, because it doesn't support the "sync" mount option. |