On Thu, Mar 07, 2024 at 03:03:44PM +0100, Jan Kara wrote: > Frankly as I'm reading the discussions here, it seems to me you are trying > to reinvent a lot of things from the filesystem space :) Like block > allocation with reasonably efficient fragmentation prevention, transparent > data compression (zswap), hierarchical storage management (i.e., moving > data between different backing stores), efficient way to get from > VMA+offset to the place on disk where the content is stored. Sure you still > don't need a lot of things modern filesystems do like permissions, > directory structure (or even more complex namespacing stuff), all the stuff > achieving fs consistency after a crash, etc. But still what you need is a > notable portion of what filesystems do. > > So maybe it would be time to implement swap as a proper filesystem? Or even > better we could think about factoring out these bits out of some existing > filesystem to share code? I definitely agree with you on this point. I had the same exact thought, reading the discussion. Filesystems already implemented a lot of solutions for fragmentation avoidance that are more apropriate for slow storage media. Also, writing chunks of any size (e.g. to directly write compressed pages) means slab-based management of swap space might not be ideal and will waste space for internal fragmentation. Also compaction for slow media is obviously harder and slower to implement compared to doing it in memory. You can do it in memory as well, but that is at the expense of more I/O. It sounds to me that all the problems above can be solved with an extent-based filesystem implementation of swap. Cheers Karim PhD student Edinburgh University
