Chuck Lever <[EMAIL PROTECTED]> wrote:
> Why not encode the local mounted-on directory in the key?
Can't. Namespaces. chroot.
> Meaning your cache is at quota all the time, and to continue operation it must
> eject items constantly.
I've thought about that, thank you. Go and read the
Hi David-
[ Some history snipped... ]
On Dec 6, 2007, at 3:00 PM, David Howells wrote:
Chuck Lever <[EMAIL PROTECTED]> wrote:
Is it a problem because, if there are multiple copies of the same
remote file
in its cache, then FS-cache doesn't know, upon reconnection,
which item to
match
Hi David-
[ Some history snipped... ]
On Dec 6, 2007, at 3:00 PM, David Howells wrote:
Chuck Lever [EMAIL PROTECTED] wrote:
Is it a problem because, if there are multiple copies of the same
remote file
in its cache, then FS-cache doesn't know, upon reconnection,
which item to
match
Chuck Lever [EMAIL PROTECTED] wrote:
Why not encode the local mounted-on directory in the key?
Can't. Namespaces. chroot.
Meaning your cache is at quota all the time, and to continue operation it must
eject items constantly.
I've thought about that, thank you. Go and read the
Chuck Lever <[EMAIL PROTECTED]> wrote:
> Why not use the fsid as well? The NFS client already uses the fsid to detect
> when it is crossing a server-side mount point.
Why use the FSID at all? The file handles are supposed to be unique per
server.
> I also note the inclusion of server IP
Hi David-
On Dec 5, 2007, at 8:22 PM, David Howells wrote:
Chuck Lever <[EMAIL PROTECTED]> wrote:
I don't see how persistent local caching means we can no longer
ignore (a)
and (b) above. Can you amplify this a bit?
How about I put it like this. There are two principal problems to
be
Hi David-
On Dec 5, 2007, at 8:22 PM, David Howells wrote:
Chuck Lever [EMAIL PROTECTED] wrote:
I don't see how persistent local caching means we can no longer
ignore (a)
and (b) above. Can you amplify this a bit?
How about I put it like this. There are two principal problems to
be
Chuck Lever [EMAIL PROTECTED] wrote:
Why not use the fsid as well? The NFS client already uses the fsid to detect
when it is crossing a server-side mount point.
Why use the FSID at all? The file handles are supposed to be unique per
server.
I also note the inclusion of server IP address in
Chuck Lever <[EMAIL PROTECTED]> wrote:
> I don't see how persistent local caching means we can no longer ignore (a)
> and (b) above. Can you amplify this a bit?
How about I put it like this. There are two principal problems to be dealt
with:
(1) Reconnection.
Imagine that the
On Dec 5, 2007, at 12:11 PM, David Howells wrote:
Okay... I'm getting to the point where I want to release my local
caching
patches again and have NFS work with them. This means making NFS
mounts share
or not share appropriately - something that's engendered a fair bit of
argument.
So I'd
On Wed, 2007-12-05 at 17:11 +, David Howells wrote:
> The downside of this is that each shared superblock only has one NFS
> connection
> to the server, and so only one set of connection parameters can be used.
> However, since persistent local caching is novel to Linux, I think that it is
>
Jon Masters <[EMAIL PROTECTED]> 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
Okay... I'm getting to the point where I want to release my local caching
patches again and have NFS work with them. This means making NFS mounts share
or not share appropriately - something that's engendered a fair bit of
argument.
So I'd like to solicit advice on how best to deal with this
Okay... I'm getting to the point where I want to release my local caching
patches again and have NFS work with them. This means making NFS mounts share
or not share appropriately - something that's engendered a fair bit of
argument.
So I'd like to solicit advice on how best to deal with this
On Dec 5, 2007, at 12:11 PM, David Howells wrote:
Okay... I'm getting to the point where I want to release my local
caching
patches again and have NFS work with them. This means making NFS
mounts share
or not share appropriately - something that's engendered a fair bit of
argument.
So I'd
Jon Masters [EMAIL PROTECTED] 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
On Wed, 2007-12-05 at 17:11 +, David Howells wrote:
The downside of this is that each shared superblock only has one NFS
connection
to the server, and so only one set of connection parameters can be used.
However, since persistent local caching is novel to Linux, I think that it is
Chuck Lever [EMAIL PROTECTED] wrote:
I don't see how persistent local caching means we can no longer ignore (a)
and (b) above. Can you amplify this a bit?
How about I put it like this. There are two principal problems to be dealt
with:
(1) Reconnection.
Imagine that the
18 matches
Mail list logo
