linux-kernel - Re: [PATCH 0/7] OMFS filesystem version 3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <E1Jmt23-0006Bq-Kk@pomaz-ex.szeredi.hu>
Date:	Fri, 18 Apr 2008 18:01:47 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	jamie@...reable.org
CC:	miklos@...redi.hu, szaka@...s-3g.org, me@...copeland.com,
	hch@...radead.org, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 0/7] OMFS filesystem version 3

> > There are also plans to add some sort of cache coherency protocol,
> > where the filesystem can asynchronously call back to fuse to
> > invalidate data or metadata.
> 
> Great!
> 
> I suggest adding another option (as well) where the filesystem can ask
> fuse to send it synchronous validation requests - some things require
> that.  (In my own work, the choice of A->B async invalidation and B->A
> synchronous validation is heuristic: some usage patterns benefit from
> one, some from the other.)

Yes, that makes sense.  I expect this could be done by extending the
existing requests with a flag saying the result is already cached.
And then the filesystem can either reply with a special "cached data
is valid" code, or it can reply normally with the fresh data.

> > > Otherwise I don't see how the kernel could coherently cache file pages
> > > for some kinds of FUSE filesystems.  (E.g. sshfs, for example: every
> > > operation must surely invoke a user space request or involve granting
> > > a caching right to the kernel, to keep accesses coherent with other
> > > users of the same remote files).
> > > 
> > > Ergo, either its not coherent, or there is some coherency protocol,
> > > which does require _some_ work in the user space implementation.
> > 
> > Sshfs is not coherent (but neither is NFS), it just has timeouts for
> > caches and invalidation based on modification time.
> 
> Fwiw, I think NFS version 4 is coherent (it uses leases), and older
> NFS should be coherent when you use fcntl file locks (it's not very
> efficient though).
> 
> I have been bitten a few times by timeout based caches in the past
> (NFS and SMB (pre-oplock)).  Simple things like editing a file, then
> running "ssh compiler-box make" from the editor quietly building
> incorrect code - and even subsequent make commands don't fix it.  Or
> when I edit a file, then tell someone I've changed the file - and then
> they edit the file, and my edits are lost.  Very annoying.  Nobody
> should build those kind of caches into new software.  :-)

Oh well, you can turn off caching if it bothers you :)  OTOH it would
be rather hard (and probably against the point) to try to extend the
sftp protocol to handle cache coherency.  Sshfs is not meant to be a
normal filesystem (although some people are trying to use it for home
directories and such), just a simple way to access remote files.

Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/