autofs: media: Always use sync option for fat*

[manu]

Summary

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

[trasz]

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?

[manu]

In D42494#969882, @trasz wrote:

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.

For 1/ yes it will be slower. But safer.
For 2/ I'm not sure tbh, how can you test something like this ?

How about decreasing the default timeout for autounmountd to eg three seconds instead?

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.

[trasz]

In D42494#969894, @manu wrote:

In D42494#969882, @trasz wrote:

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.

For 1/ yes it will be slower. But safer.

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.

For 2/ I'm not sure tbh, how can you test something like this ?

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.

How about decreasing the default timeout for autounmountd to eg three seconds instead?

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.

Doesn't unmount(2) syscall sync the filesystem even when it fails to unmount it due to being busy?

[manu]

In D42494#970339, @trasz wrote:

In D42494#969894, @manu wrote:

In D42494#969882, @trasz wrote:

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.

For 1/ yes it will be slower. But safer.

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.

FreeBSD users don't tend to understand how to use media :)

For 2/ I'm not sure tbh, how can you test something like this ?

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.

How about decreasing the default timeout for autounmountd to eg three seconds instead?

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.

Doesn't unmount(2) syscall sync the filesystem even when it fails to unmount it due to being busy?

Maybe, but unmount will not be called if the user remove the drive before autounmound kicks in.

[brooks]

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.

[manu]

Using this quick and dirty test script : https://dpaste.com/37CL5BKK5
Here is the result :
-----------------------------------------------------------------------------------------------------------------------------+

x + + +*x ++ ++ xxx + + x x x
	_____	_____________A_________M__	___A____________________________________

+-----------------------------------------------------------------------------------------------------------------------------+

N           Min           Max        Median           Avg        Stddev

x 10 27.8 77.94 49.09 52.032 14.910511
+ 10 35.46 55.44 45.005 45.03 5.4061364
No difference proven at 95.0% confidence

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).
It was run on a Corsair Voyager USB3 thumb drive on a fat32 partition.

[trasz]

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.

[manu]

In D42494#970691, @trasz wrote:

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.

I will test all the fs and update the review accordingly.

[manu]

Use sync only for fat/ntfs filesystems.