Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Swap Abstraction "the pony"

[Karim Manaouil <kmanaouil.dev@gmail.com>]

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