On 18/11/24 10:36, Samuel Sieb wrote:
I know there is a huge difference in price points, but 40 years ago mainframe storage controllers provided functionality to control what files were loaded into the storage cache and how much of the file was loaded, I just thought hard disks had advanced enough to now provide similar functionality. I was so much concerned about seek overheads, but rpsmiss overheads and the impact fragmentation has on that particularly if a load of a file has to traverse all over the disk to do so. But having said this I'll put this to bed, I may have found what is causing the KDE start up hard disk thrashing.Yes, a full cache can cause performance issues, but I would expect to be able to play around with the caching algorithms to control what gets cached and what doesn't, particularly when looking at sequential vs random access, combined with disk fragmentation. I know EXT4 is a journaling file system which is supposed to make fragmentation a non- issue, but I don't know whether BTRFS is the same.That's not the cache that's meant. He was referring to the hard disk internal cache. You have no control over that. The filesystem could be a factor for seek times, but it shouldn't be that much.
regards, Steve
OpenPGP_0x1EBE7C07B0F7242C.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
