On Wed, Jan 31, 2024 at 6:36 AM Leon Fauster via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > 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. This is a huge point. For someone writing something quickly to a USB stick, the behavior characteristic of sync is not entirely horrible. For people with large USB drives frequently or always mounted, the expectations are completely different. As USB gets faster, and laptops/nucs/etc get smaller, we see more and more people using USB SSDs to expand storage. Justin > > >> 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 -- _______________________________________________ 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
