Linux's Local Cache For Network Filesystems Seeing Huge Speed-Up, Lower Memory Use

[phoronix]

Phoronix: Linux's Local Cache For Network Filesystems Seeing Huge Speed-Up, Lower Memory Use

David Howells of Red Hat has been working to "massively overhaul" the code surrounding the kernel's local caching for network filesystems...

http://www.phoronix.com/scan.php?page=news_item&px=FSCache-IO-Rewrite

[schmidtbag]

When there is that much trimming going on, I can't help but question if perhaps too much was removed. If everything is fully functional then this is great news.

[caligula]

When there is that much trimming going on, I can't help but question if perhaps too much was removed. If everything is fully functional then this is great news.

This isn't something you use every day. I've seen some local networks where they provide /home and /usr via NFS and the biggest annoyance is that they don't cache anything or only in memory (no cachefilesd). As a result, the network fs is pretty slow.

[alpha_one_x86]

How many is big improvement?

[xnor]

How many is big improvement?

Very many. At least six.

[AndyChow]

Very many. At least six.

Is six a lot?

[CochainComplex]

Is six a lot?

6*n is a lot

[NotMine999]

Is six a lot?

It's definitely more than 5 and a lot more than 1.

[skerit]

Good to hear it's still being worked on! A bug got in the fscache code of the 5.6 kernel, causing it to randomly crash. Getting back access to your NFS mount is impossible without a reboot. Had to disable the cache because of that

https://bugzilla.kernel.org/show_bug.cgi?id=207217

[CommunityMember]

When there is that much trimming going on ....

It is not unusual for sections of code in large code bases that work to be ignored for long periods of time until someone has a reason to look at it, and then realizes that it can be refactored and substantially improved (sometimes just by thinking different, sometimes by take advantage of new approaches that other functions now provide). We constantly see posts on phoronix about targeted speedups from numerous contributors in specific code sections on Linux. I don't think fscache is any different here.

David has a long history of good work in the file system area. He has and continues to contribute to at least nfs, pipe, ceph, afs, and, of course, fscache (and probably other filesystems, too, just are just what I recall). I, for one, expect this to be another win for Linux.