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  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:	Wed, 05 Dec 2007 18:03:58 +0000
From:	David Howells <>
To:	Jon Masters <>
Cc:, Peter Staubach <>,
	Trond Myklebust <>,
	Steve Dickson <>,,
Subject: Re: How to manage shared persistent local caching (FS-Cache) with NFS?

Jon Masters <> wrote:

> I think the shared superblock approach is the right one, but I'm a
> little concerned that there would now be different behavior for fscache
> and non-cached setups. Not sure of any better idea though.

The behaviour varies a bit anyway because there's a cache...

> > The R/O mount flag can be dealt with by moving readonlyness into the
> > vfsmount rather than having it a property of the superblock.  The
> > superblock would then be read-only only if all its vfsmounts are also
> > read-only.
> Given that, how many connection parameters are there that are likely to
> actually differ on the same client, talking to the same server? Really?

I don't have figures on that, but I do know people have complained about it
for non-cached conditions.

> You could store the table in a NIS map, for example, and a udev rule or
> similar could trigger to load it later.

My point was meant to be that the presence and coverage of a cache is more
likely to reflect the client machine than would the NIS map for the NFS
automounts.  You wouldn't necessarily want to store this table in NIS.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists