[OpenAFS] Re: stackable file system above OpenAFS

Andrew Deason adeason@sinenomine.net
Thu, 25 Sep 2014 10:13:49 -0500

This is a multi-part message in MIME format.

Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 25 Sep 2014 13:20:07 +0200 (CEST)
Erik Braun <erik.braun@uni-jena.de> wrote:

> > As I mention in that linked message, the OpenAFS code maybe doesn't
> > need to be like that. I could give you a patch that would avoid this
> > issue, but I'm not sure if it causes any other problems; more time
> > would need to be spent looking at it to be sure. (Or you can just
> > try it and see what happens.)
> I really would appreciate it if you send me this patch.

Attached. As I said, I don't know if this break anything else (if it was
broken, you might see file changes not be reflected in the client). It's
been a while since I looked at this, so I may have things wrong; if
things still hang, just give us a backtrace again.

To try to briefly explain what this is about:

Our file data gets into the Linux page cache when accessed. When a file
changes, we need to invalidate ("flush") the pages from when before the
file was changed. Right now we detect if this happens and perform the
flush during a few operations (open, read, mmap, maybe a few others).
AUFS doesn't like that we do it during open because of how their locking
works, so this patch just gets rid of the call during 'open'.

That may be fine if we also flush pages in all other cases, and nothing
relies on pages being updated after an 'open' but before the other
calls. But I don't know if that's true. It's also possible to change
when we flush pages completely, and do it when callbacks are broken or
expired or something like that, but that has further consequences that
we'd need to think about.

Andrew Deason

Content-Type: application/octet-stream;
Content-Disposition: attachment;
Content-Transfer-Encoding: base64