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.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.
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.
regards,
Steve
Attachment:
OpenPGP_0x1EBE7C07B0F7242C.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-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/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
