Am 31.01.24 um 09:57 schrieb Larina Loriasel via devel:
'sync' has some strong downsides though: various operations become
painfully slow (this depends a lot on the hardware and its age, and
the history of previous writes, etc.), write operations block read
operations, and the total number of writes may be increased, leading
to more wear&tear on the hardware.
The udev rule only applies to USB Storage devices, and I think the total number of writes increasing only happens if the data to be written is changed constantly (e.g. writes that overlap on same region/block of a device)
Most USB Storage devices are used for storing simple, consecutive streams of data, such as Music, Pictures and other simple files and are not usually modified much, thus, I think enabling sync makes sense in this regard.
In my opinion, the benefits of mounting USB Storage devices with sync outweigh the detriments.
Writes blocking reads is concerning.
Thats a to narrow view, as the USB interface is used in a ton of
scenarios (backups etc.) where maximum data flow is an expectation.
We approach this problem from a different angle: the user is supposed
to sync the filesystem before removing. Graphical environments have
an "eject" button, and for non-graphical environments, the user
just needs to do a sync manually.
I am aware of that, but it leads to a poor user experience, being notified that a copying operation has been completed, while in reality, it has not.
CLI: Doesn't that trigger the umount command already ... so no need to
think about it (as user). As soon the umount completes the device can be
unplugged.
The same is true for "normal" writes to a harddrive. Operations are
generally async, and the user needs to do a shutdown, during which
we sync and unmount filesystems. If you "yank" the cord, this may (*)
result in lost data and file system inconsistency.
My proposal was exclusively for USB Storage devices, not internal ones, as I can understand the benefits of async outweighing the detriments in the case of internal/network etc storage devices.
I never had a big issue in the GUI (long time/waits), as it clearly
states to wait until removal is allowed (also stated via notify).
Normally (here) this is just a few seconds (single digit).
Maybe the idea can be implemented more transparently via vm.dirty_*
sysctl per device if possible or is it a global threshold only?
--
Leon
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue