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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to