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]

Date:	Fri, 18 Apr 2008 14:20:35 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	jamie@...reable.org
CC:	szaka@...s-3g.org, me@...copeland.com, miklos@...redi.hu,
	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

> Szabolcs Szakacsits wrote:
> > If you have the free hot caches then it performs the same as in-kernel 
> > file systems, user space isn't involved at all.
> 
> Presumably if "user space isn't involved at all", it must require that
> user space has granted caching rights to the kernel over a FUSE
> cache coherency protocol?
> 

Most filesystems (ntfs-3g included) cannot be modified from the
outside, so coherency isn't an issue.

Otherwise currently fuse provides rather crude settings for caching:

  - timeout for attributes (per-inode, default 1s)
  - timeout for names (per-dentry, default 1s)
  - page cache is bypassed completely (per-file, default off)
  - invalidation of page cache on open (per-open, default on)

Writes are synchronous even in the caching case, for various reasons.
That is one of the reasons why write performance can be worse than
read performance.  For some filesystems (ntfs-3g), this limitation
could be lifted, but that requires that the mtime handling be moved to
the kernel in these cases, which is not yet possible.

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.

> 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.

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/