KDE

5259 readers

190 users here now

KDE is an international technology team creating user-friendly free and open source software for desktop and portable computing. KDE’s software runs on GNU/Linux, BSD and other operating systems, including Windows.

Plasma 6 Bugs

If you encounter a bug, proceed to https://bugs.kde.org, check whether it has been reported.

If it hasn't, report it yourself.

PLEASE THINK CAREFULLY BEFORE POSTING HERE.

Developers do not look for reports on social media, so they will not see it and all it does is clutter up the feed.

founded 1 year ago

MODERATORS

[email protected]

How do I stop KDE from saving files to RAM before copying to disk? (lemmy.world)

submitted 10 months ago by [email protected] to c/[email protected]

4 comments fedilink hide all child comments

I don't like that the KDE file transfer progress does not take in account the transfer from RAM to disk, and it only takes into account disk to RAM. I don't want to wait for the "Don't eject yet" message to disappear, because it sometimes stays too long, and I get worried if there could be an issue with KDE. How do I make:

KDE/Dolphin take into account RAM to disk in progress, or
Make KDE/Dolphin send files straight to disk, without sending to RAM.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 16 points 10 months ago (1 children)

That's a kernel thing that dates from the 90s where allocating a quarter to half of your RAM for write caching made sense. These days we have more RAM than the USB stick we're writing to, so it fits well into the buffer to be flushed asynchronously.

You can tweak some sysctls to make it less of a thing: https://unix.stackexchange.com/a/640826

[–] [email protected] 10 points 10 months ago

Bit more context behind that now that the coffee kicked in:

Back then everyone had HDDs which strongly prefers sequential reads and writes. So if you can buffer all those in RAM, the system can optimize the throughput.
For the most part, IO happens on internal, non-removable drives so it makes sense to let applications write to RAM and do the flushing to disk in the background. For example, Firefox can write to its cache without having to worry whether it'll slow down the browser too much. Generally makes applications much snappier, especially single threaded ones that vastly predates async runtimes.
If the program does IO on multiple drives, by acknowledging the write on one immediately may let the program perform IO on the next file, which the kernel can then flush to both drives in parallel.
By acknowledging the write immediately, the modified file is also immediately available to other programs on the system which can access the file immediately, from RAM, as it's still being flushed to disk in the background.
The buffering allows writes to potentially cancel a pending write. If you're updating multiple files for example, the kernel can delay updating the filesystem state to do it just once with the updated file list.
That's largely why Linux works so much better with millions of tiny files compared to Windows.
You can still get speed benefits even with modern NVMe doing this. Those are so fast the kernel can run out of stuff to write before it's gotten around to wake up the application for more. Instead let the application fill up the buffer fast, and only then, block the application.

Pretty much the only time this matters and becomes confusing is when you're copying a file and wanted an accurate transfer rate, and the target disk is much slower than the rest of the computer, ie. USB sticks and SD cards.

Example case: updating your system. The package manager will write a whole bunch of files everywhere, but also run a bunch of commands to update some other files, rebuild caches and indexes, maybe do some computations and compiling. The package manager will call sync at the end of the process, and it's likely by the time you get there, most of the data will have been flushed to disk. So it runs much faster.