Re: [RFC PATCH tarfs 0/6] mmap support for tarfs

[Samuel Thibault]

Sergey Bugaev, le sam. 01 mai 2021 19:15:50 +0300, a ecrit:
> On Sat, May 1, 2021 at 6:38 PM Samuel Thibault <samuel.thibault@gnu.org> 
> wrote:
> > Actually I'd say the pager should replace the cache. The pager is
> > already a cache by itself, we should not need to keep both the pager and
> > the cache, particularly since it means having to keep both coherent.
> 
> Well, yes, I've considered that; but I've tried to keep the changes
> less invasive than that.

I understand, but sometimes it's much better to be invasive than to try
to keep the existing code, at the cost of contorsions.

> This actually brings me to a question: why is tarfs using netfs over
> diskfs?

I don't know, Ludo?

> on the other hand, the tar format, with its 512-byte
> blocks, sounds very much like a filesystem image to me. isofs uses
> diskfs, why doesn't tarfs?

It's not exactly the same since you have compression in the way. But
yes, that looks similar enough.

> 1. S_io_write ()
> 2. lock the node, validate size/offset, grow it if needed
> 3. pager_memcpy (), fault
> 4. another thread (!) gets to pager_{read,write}_page ()

Ok, I was thinking something about this but didn't dive to make sure
that was your scenario.

> This is why the mutex cannot be made recursive: it's being grabbed
> from the other thread. And this is also why I cannot just extract the
> logic: I'm not calling the logic inside pager.c directly, I'm calling
> pager_memcpy (), which faults and *that* causes
> pager_{read,write}_page () to be called the same way it'd be called
> for any other task faulting on the mapping. And
> pager_{read,write}_page () naturally has to lock, to validate the
> size, access the cache, and whatnot.
> 
> Perhaps you can think of a solution? How does diskfs cope with this?

Diskfs' pager_read_page does *not* have to lock the node, it just reads
and returns the data. That's again a point where you see that having
also the cache is in the way rather than helping.

Samuel