On Monday April 16, [EMAIL PROTECTED] wrote:
>
> The challenge is making it be stable across inserts/deletes, never
> mind reboots. And it's not a "little bit of cacheing"; in order to be
> correct we would have to cache *forever*, since at least in theory an
> NFS client could hold on to a
On Mon, Apr 16, 2007 at 04:18:53PM +1000, Neil Brown wrote:
> On Thursday April 12, [EMAIL PROTECTED] wrote:
> >
> > Unfortunately, in the NFS case if there are hash collisions, under the
> > wrong circumstances the NFS client could loop forever trying to
> > readdir() a directory stream.
>
> I
On Mon, Apr 16, 2007 at 03:47:21PM +1000, Neil Brown wrote:
> "my guess", "pretty much" really bother me.
>
> It sounds like "The largest anyone has asked for is 128bits, or let's
> double it and hope that is enough until the next protocol revision".
> Which was probably reasonable when NFSv2 was
On Thursday April 12, [EMAIL PROTECTED] wrote:
>
> Unfortunately, in the NFS case if there are hash collisions, under the
> wrong circumstances the NFS client could loop forever trying to
> readdir() a directory stream.
I think that can be easily avoided by the filesystem by simply
ensuring that
On Thursday April 12, [EMAIL PROTECTED] wrote:
Unfortunately, in the NFS case if there are hash collisions, under the
wrong circumstances the NFS client could loop forever trying to
readdir() a directory stream.
I think that can be easily avoided by the filesystem by simply
ensuring that the
On Mon, Apr 16, 2007 at 03:47:21PM +1000, Neil Brown wrote:
my guess, pretty much really bother me.
It sounds like The largest anyone has asked for is 128bits, or let's
double it and hope that is enough until the next protocol revision.
Which was probably reasonable when NFSv2 was being
On Mon, Apr 16, 2007 at 04:18:53PM +1000, Neil Brown wrote:
On Thursday April 12, [EMAIL PROTECTED] wrote:
Unfortunately, in the NFS case if there are hash collisions, under the
wrong circumstances the NFS client could loop forever trying to
readdir() a directory stream.
I think that
On Monday April 16, [EMAIL PROTECTED] wrote:
The challenge is making it be stable across inserts/deletes, never
mind reboots. And it's not a little bit of cacheing; in order to be
correct we would have to cache *forever*, since at least in theory an
NFS client could hold on to a cookie for
On Sunday April 15, [EMAIL PROTECTED] wrote:
> On Thu, Apr 12, 2007 at 10:35:49AM -0700, H. Peter Anvin wrote:
> >
> > Any fixed size is too small. It should be a dynamic size.
>
> Idally it should be dynamic, but my guess is that if the cookie were a
> fixed 256 bits, it would be sufficient
On Thu, Apr 12, 2007 at 10:35:49AM -0700, H. Peter Anvin wrote:
> J. Bruce Fields wrote:
> >On Thu, Apr 12, 2007 at 08:21:16AM -0400, Theodore Tso wrote:
> >>Again, compared to a directory fd cache, what you're proposing a huge
> >>hit to the filesystem, and at the moment, given that
On Thu, Apr 12, 2007 at 10:35:49AM -0700, H. Peter Anvin wrote:
J. Bruce Fields wrote:
On Thu, Apr 12, 2007 at 08:21:16AM -0400, Theodore Tso wrote:
Again, compared to a directory fd cache, what you're proposing a huge
hit to the filesystem, and at the moment, given that telldir/seekdir
is
On Sunday April 15, [EMAIL PROTECTED] wrote:
On Thu, Apr 12, 2007 at 10:35:49AM -0700, H. Peter Anvin wrote:
Any fixed size is too small. It should be a dynamic size.
Idally it should be dynamic, but my guess is that if the cookie were a
fixed 256 bits, it would be sufficient for pretty
J. Bruce Fields wrote:
On Thu, Apr 12, 2007 at 08:21:16AM -0400, Theodore Tso wrote:
Again, compared to a directory fd cache, what you're proposing a huge
hit to the filesystem, and at the moment, given that telldir/seekdir
is rarely used by everyone else, it's mainly NFS which is the main bad
On Thu, Apr 12, 2007 at 08:21:16AM -0400, Theodore Tso wrote:
> Again, compared to a directory fd cache, what you're proposing a huge
> hit to the filesystem, and at the moment, given that telldir/seekdir
> is rarely used by everyone else, it's mainly NFS which is the main bad
> actor here by
On Thu, Apr 12, 2007 at 03:57:41PM +1000, Neil Brown wrote:
> But my perspective is that a solution in nfsd at-best a work-around.
> Caching the whole 'struct file' when there is just a small bit that we
> might want seems like a heavy hammer. The filesystem is in the best
> place to know what
On Thu, 12 April 2007 15:57:41 +1000, Neil Brown wrote:
>
> > However, the collision chain gives me quite a bit of headache. One
> > would have to store each entry's position on the chain, deal with older
> > entries getting deleted, newer entries getting removed, etc. All this
> > requires a
On Thursday April 12, [EMAIL PROTECTED] wrote:
> On Thu, 12 April 2007 11:46:41 +1000, Neil Brown wrote:
> >
> > I could argue that nfs came before ext3+dirindex, so ext3 should have
> > been designed to work properly with NFS. You could argue that fixing
> > it in nfsd fixes it for all
On Thursday April 12, [EMAIL PROTECTED] wrote:
On Thu, 12 April 2007 11:46:41 +1000, Neil Brown wrote:
I could argue that nfs came before ext3+dirindex, so ext3 should have
been designed to work properly with NFS. You could argue that fixing
it in nfsd fixes it for all filesystems. But
On Thu, 12 April 2007 15:57:41 +1000, Neil Brown wrote:
However, the collision chain gives me quite a bit of headache. One
would have to store each entry's position on the chain, deal with older
entries getting deleted, newer entries getting removed, etc. All this
requires a lot of
On Thu, Apr 12, 2007 at 03:57:41PM +1000, Neil Brown wrote:
But my perspective is that a solution in nfsd at-best a work-around.
Caching the whole 'struct file' when there is just a small bit that we
might want seems like a heavy hammer. The filesystem is in the best
place to know what needs
On Thu, Apr 12, 2007 at 08:21:16AM -0400, Theodore Tso wrote:
Again, compared to a directory fd cache, what you're proposing a huge
hit to the filesystem, and at the moment, given that telldir/seekdir
is rarely used by everyone else, it's mainly NFS which is the main bad
actor here by
J. Bruce Fields wrote:
On Thu, Apr 12, 2007 at 08:21:16AM -0400, Theodore Tso wrote:
Again, compared to a directory fd cache, what you're proposing a huge
hit to the filesystem, and at the moment, given that telldir/seekdir
is rarely used by everyone else, it's mainly NFS which is the main bad
On Thu, 12 April 2007 11:46:41 +1000, Neil Brown wrote:
>
> I could argue that nfs came before ext3+dirindex, so ext3 should have
> been designed to work properly with NFS. You could argue that fixing
> it in nfsd fixes it for all filesystems. But I'm not sure either of
> those arguments are
On Wednesday April 11, [EMAIL PROTECTED] wrote:
>
> Actually, no, we can't keep the collision chain count stable across a
> create/delete even while the tree is cached. At least, not without
> storing a huge amount of state associated with each page. (It would
> be a lot more work than simply
On Wednesday April 11, [EMAIL PROTECTED] wrote:
> On Thu, 12 Apr 2007, Neil Brown wrote:
>
> > For the second.
> > You say that you " would need at least 96 bits in order to make that
> > guarantee; 64 bits of hash, plus a 32-bit count value in the hash
> > collision chain". I think 96 is a
On Wed, 11 April 2007 16:23:21 -0700, H. Peter Anvin wrote:
> David Lang wrote:
> >On Thu, 12 Apr 2007, Neil Brown wrote:
> >
> >>For the second.
> >> You say that you " would need at least 96 bits in order to make that
> >> guarantee; 64 bits of hash, plus a 32-bit count value in the hash
> >>
David Lang wrote:
On Thu, 12 Apr 2007, Neil Brown wrote:
For the second.
You say that you " would need at least 96 bits in order to make that
guarantee; 64 bits of hash, plus a 32-bit count value in the hash
collision chain". I think 96 is a bit greedy. Surely 48 bits of
hash and 16 bits
On Thu, Apr 12, 2007 at 08:32:05AM +1000, Neil Brown wrote:
> For the first:
> You are storing an internal tree representation of part of the
> directory attached to the 'struct file'.
> Would it be possible to store this attached to the page via the
> ->private pointer? What would avoid
On Thu, 12 Apr 2007, Neil Brown wrote:
For the second.
You say that you " would need at least 96 bits in order to make that
guarantee; 64 bits of hash, plus a 32-bit count value in the hash
collision chain". I think 96 is a bit greedy. Surely 48 bits of
hash and 16 bits of
On Wednesday April 11, [EMAIL PROTECTED] wrote:
> On Wed, Apr 11, 2007 at 07:15:57AM +1000, Neil Brown wrote:
> > > Neil, is this correct?
> >
> > It's just NFS. nfsd does open/getdents/close on every readdir
> > request.
>
> That's... unfortunate.
I like to think of it as "challenging" :-)
>
On Wed, Apr 11, 2007 at 07:15:57AM +1000, Neil Brown wrote:
> > Neil, is this correct?
>
> It's just NFS. nfsd does open/getdents/close on every readdir
> request.
That's... unfortunate.
Ext3 w/htree enable creates an in-memory red-black tree of a portion
of the directory; this is typically
On Apr 11 2007 07:15, Neil Brown wrote:
>On Sunday April 8, [EMAIL PROTECTED] wrote:
>> On Sun, 8 April 2007 11:11:20 -0700, H. Peter Anvin wrote:
>> >
>> > Well, the question is if you can keep the seekdir/telldir cookie around
>> > as a pointer -- preferrably in userspace, of course. You
On Apr 11 2007 07:15, Neil Brown wrote:
On Sunday April 8, [EMAIL PROTECTED] wrote:
On Sun, 8 April 2007 11:11:20 -0700, H. Peter Anvin wrote:
Well, the question is if you can keep the seekdir/telldir cookie around
as a pointer -- preferrably in userspace, of course. You would
On Wed, Apr 11, 2007 at 07:15:57AM +1000, Neil Brown wrote:
Neil, is this correct?
It's just NFS. nfsd does open/getdents/close on every readdir
request.
That's... unfortunate.
Ext3 w/htree enable creates an in-memory red-black tree of a portion
of the directory; this is typically one
On Wednesday April 11, [EMAIL PROTECTED] wrote:
On Wed, Apr 11, 2007 at 07:15:57AM +1000, Neil Brown wrote:
Neil, is this correct?
It's just NFS. nfsd does open/getdents/close on every readdir
request.
That's... unfortunate.
I like to think of it as challenging :-)
So the
On Thu, 12 Apr 2007, Neil Brown wrote:
For the second.
You say that you would need at least 96 bits in order to make that
guarantee; 64 bits of hash, plus a 32-bit count value in the hash
collision chain. I think 96 is a bit greedy. Surely 48 bits of
hash and 16 bits of
On Thu, Apr 12, 2007 at 08:32:05AM +1000, Neil Brown wrote:
For the first:
You are storing an internal tree representation of part of the
directory attached to the 'struct file'.
Would it be possible to store this attached to the page via the
-private pointer? What would avoid the
David Lang wrote:
On Thu, 12 Apr 2007, Neil Brown wrote:
For the second.
You say that you would need at least 96 bits in order to make that
guarantee; 64 bits of hash, plus a 32-bit count value in the hash
collision chain. I think 96 is a bit greedy. Surely 48 bits of
hash and 16 bits
On Wed, 11 April 2007 16:23:21 -0700, H. Peter Anvin wrote:
David Lang wrote:
On Thu, 12 Apr 2007, Neil Brown wrote:
For the second.
You say that you would need at least 96 bits in order to make that
guarantee; 64 bits of hash, plus a 32-bit count value in the hash
collision chain. I
On Wednesday April 11, [EMAIL PROTECTED] wrote:
On Thu, 12 Apr 2007, Neil Brown wrote:
For the second.
You say that you would need at least 96 bits in order to make that
guarantee; 64 bits of hash, plus a 32-bit count value in the hash
collision chain. I think 96 is a bit greedy.
On Wednesday April 11, [EMAIL PROTECTED] wrote:
Actually, no, we can't keep the collision chain count stable across a
create/delete even while the tree is cached. At least, not without
storing a huge amount of state associated with each page. (It would
be a lot more work than simply having
On Thu, 12 April 2007 11:46:41 +1000, Neil Brown wrote:
I could argue that nfs came before ext3+dirindex, so ext3 should have
been designed to work properly with NFS. You could argue that fixing
it in nfsd fixes it for all filesystems. But I'm not sure either of
those arguments are likely
In article <[EMAIL PROTECTED]> you wrote:
> Otherwise, the client would have to cache _all_ previous READDIR results
> since the last opendir()/rewinddir() in order to be able to do its own
> loop detection and that will obviously never scale for large directories
> or for directories that change
On Wed, 2007-04-11 at 08:33 +1000, Neil Brown wrote:
> A READDIR (aka getdents2) should take a directory handle, a cookie,
> and a filename, and should return filenames and cookies. The
> cookies may all be identical or may not. The filename might be used
> by the filesystem, or it
On Tuesday April 10, [EMAIL PROTECTED] wrote:
> On Wed, 2007-04-11 at 07:37 +1000, Neil Brown wrote:
> > On Tuesday April 10, [EMAIL PROTECTED] wrote:
> > > On Wed, 2007-04-11 at 07:12 +1000, Neil Brown wrote:
> > > >
> > > > Is there something that makes that interface problematic?
> > >
> > >
On Wed, 2007-04-11 at 07:37 +1000, Neil Brown wrote:
> On Tuesday April 10, [EMAIL PROTECTED] wrote:
> > On Wed, 2007-04-11 at 07:12 +1000, Neil Brown wrote:
> > >
> > > Is there something that makes that interface problematic?
> >
> > File deletions...
>
> How are they a problem ?
>
> There
On 4/10/07, Neil Brown <[EMAIL PROTECTED]> wrote:
2/ Some data structure using an ordered search key that is based on
the filename (e.g. a B-tree with a search key that is a hash of the
filename).
In the first case, you just use a fixed opaque cookie for location in
a directory.
In the
On Sunday April 8, [EMAIL PROTECTED] wrote:
> On Sun, 8 April 2007 11:11:20 -0700, H. Peter Anvin wrote:
> >
> > Well, the question is if you can keep the seekdir/telldir cookie around
> > as a pointer -- preferrably in userspace, of course. You would
> > presumably garbage-collect them on
> A READDIR request contains either a cookie or a filename. Either mean
> "This identifies the last name I got from you, give me the next one".
>
> Is there something that makes that interface problematic?
Another client may have removed the name and re-added a new file with
that name. At this
On Tuesday April 10, [EMAIL PROTECTED] wrote:
>
> Seems like it would simply make more sense for the server to be allowed
> to determine what the size of the cookie should be.
That is one possibility. but if the cookie gets too big, you
substantially reduce the number of entries you can fit in
On Tuesday April 10, [EMAIL PROTECTED] wrote:
> On Wed, 2007-04-11 at 07:12 +1000, Neil Brown wrote:
> >
> > Is there something that makes that interface problematic?
>
> File deletions...
How are they a problem ?
There are only two ways to organise a directory.
1/ Unsorted linear list of
On Monday April 9, [EMAIL PROTECTED] wrote:
> On Mon, Apr 09, 2007 at 08:31:37AM -0400, Trond Myklebust wrote:
> > That is a protocol limitation, not a client limitation.
>
>
>
> And after quickly checking RFC 3010, I see this limitation hasn't been
> lifted in NFSv4.
>
> Speaking of which,
On Wed, 2007-04-11 at 07:12 +1000, Neil Brown wrote:
> On Tuesday April 10, [EMAIL PROTECTED] wrote:
> > The problem is that it is extremely hard to come up with an alternative
> > that doesn't impose new conditions on what filesystems you can support.
>
> I seem to remember Hans Reiser making a
Neil Brown wrote:
On Tuesday April 10, [EMAIL PROTECTED] wrote:
The problem is that it is extremely hard to come up with an alternative
that doesn't impose new conditions on what filesystems you can support.
I seem to remember Hans Reiser making a credible suggestion years ago
when NFSv4 was
On Tuesday April 10, [EMAIL PROTECTED] wrote:
> The problem is that it is extremely hard to come up with an alternative
> that doesn't impose new conditions on what filesystems you can support.
I seem to remember Hans Reiser making a credible suggestion years ago
when NFSv4 was still in draft.
On 4/10/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
It rather makes any user space accesses irrelevant. The main question
seems to be if we can realistically increase the cookie size even to 64
bits.
On 32-bit platforms, *not* using _FILE_OFFSET_BITS=64 is already today
a stupid thing to
ld also give a 'fixed view' when adding/deleting files
> during readdir.
What should happen if the directory contents go stale? If *two* systems
cache the directory and then proceed to add/delete files, what happens?
pgpKUxNQKTp2A.pgp
Description: PGP signature
Jan Engelhardt wrote:
I had a thought, but I think it's not quite ripe..
NFS server sends the whole directory contents on NFS client opendir,
so that the whole readdir/telldir/seekdir magic can happen on the
client only... which would perhaps also enable a cheap telldir/seekdir,
and would also
On Apr 10 2007 10:37, Trond Myklebust wrote:
>
>NFS, OTOH, simply could not work without that requirement, since there
>exists no file pointer to tell you where you are in a stream beyond
>whatever the server manages to encode inside the opaque cookie+verifier.
>
>> But the fact of the matter is
Ulrich Drepper wrote:
On 4/10/07, Theodore Tso <[EMAIL PROTECTED]> wrote:
That might work. But if in the long term we want to separate out what
we can send back via telldir/seekdir, and some future new Posix
interface, [...]
With all these discussions about fixes for telldir, do we want to
On Tue, 2007-04-10 at 09:56 -0400, Theodore Tso wrote:
> That might work. But if in the long term we want to separate out what
> we can send back via telldir/seekdir, and some future new Posix
> interface, I wonder if we might be better off defining a formal
> interface which can be used by
On 4/10/07, Theodore Tso <[EMAIL PROTECTED]> wrote:
That might work. But if in the long term we want to separate out what
we can send back via telldir/seekdir, and some future new Posix
interface, [...]
With all these discussions about fixes for telldir, do we want to
persue an alternative
On Mon, Apr 09, 2007 at 10:03:15AM -0400, Trond Myklebust wrote:
> We could perhaps teach nfsd to open the file without the O_LARGEFILE
> attribute in the case of NFSv2?
That might work. But if in the long term we want to separate out what
we can send back via telldir/seekdir, and some future
On Mon, Apr 09, 2007 at 10:03:15AM -0400, Trond Myklebust wrote:
We could perhaps teach nfsd to open the file without the O_LARGEFILE
attribute in the case of NFSv2?
That might work. But if in the long term we want to separate out what
we can send back via telldir/seekdir, and some future new
On 4/10/07, Theodore Tso [EMAIL PROTECTED] wrote:
That might work. But if in the long term we want to separate out what
we can send back via telldir/seekdir, and some future new Posix
interface, [...]
With all these discussions about fixes for telldir, do we want to
persue an alternative
On Tue, 2007-04-10 at 09:56 -0400, Theodore Tso wrote:
That might work. But if in the long term we want to separate out what
we can send back via telldir/seekdir, and some future new Posix
interface, I wonder if we might be better off defining a formal
interface which can be used by NFSv2
Ulrich Drepper wrote:
On 4/10/07, Theodore Tso [EMAIL PROTECTED] wrote:
That might work. But if in the long term we want to separate out what
we can send back via telldir/seekdir, and some future new Posix
interface, [...]
With all these discussions about fixes for telldir, do we want to
On Apr 10 2007 10:37, Trond Myklebust wrote:
NFS, OTOH, simply could not work without that requirement, since there
exists no file pointer to tell you where you are in a stream beyond
whatever the server manages to encode inside the opaque cookie+verifier.
But the fact of the matter is that if
Jan Engelhardt wrote:
I had a thought, but I think it's not quite ripe..
NFS server sends the whole directory contents on NFS client opendir,
so that the whole readdir/telldir/seekdir magic can happen on the
client only... which would perhaps also enable a cheap telldir/seekdir,
and would also
view' when adding/deleting files
during readdir.
What should happen if the directory contents go stale? If *two* systems
cache the directory and then proceed to add/delete files, what happens?
pgpKUxNQKTp2A.pgp
Description: PGP signature
On 4/10/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
It rather makes any user space accesses irrelevant. The main question
seems to be if we can realistically increase the cookie size even to 64
bits.
On 32-bit platforms, *not* using _FILE_OFFSET_BITS=64 is already today
a stupid thing to do.
On Tuesday April 10, [EMAIL PROTECTED] wrote:
The problem is that it is extremely hard to come up with an alternative
that doesn't impose new conditions on what filesystems you can support.
I seem to remember Hans Reiser making a credible suggestion years ago
when NFSv4 was still in draft. It
Neil Brown wrote:
On Tuesday April 10, [EMAIL PROTECTED] wrote:
The problem is that it is extremely hard to come up with an alternative
that doesn't impose new conditions on what filesystems you can support.
I seem to remember Hans Reiser making a credible suggestion years ago
when NFSv4 was
On Wed, 2007-04-11 at 07:12 +1000, Neil Brown wrote:
On Tuesday April 10, [EMAIL PROTECTED] wrote:
The problem is that it is extremely hard to come up with an alternative
that doesn't impose new conditions on what filesystems you can support.
I seem to remember Hans Reiser making a
On Monday April 9, [EMAIL PROTECTED] wrote:
On Mon, Apr 09, 2007 at 08:31:37AM -0400, Trond Myklebust wrote:
That is a protocol limitation, not a client limitation.
Groan
And after quickly checking RFC 3010, I see this limitation hasn't been
lifted in NFSv4.
Speaking of which, right
On Tuesday April 10, [EMAIL PROTECTED] wrote:
On Wed, 2007-04-11 at 07:12 +1000, Neil Brown wrote:
Is there something that makes that interface problematic?
File deletions...
How are they a problem ?
There are only two ways to organise a directory.
1/ Unsorted linear list of entries in
On Tuesday April 10, [EMAIL PROTECTED] wrote:
Seems like it would simply make more sense for the server to be allowed
to determine what the size of the cookie should be.
That is one possibility. but if the cookie gets too big, you
substantially reduce the number of entries you can fit in a
A READDIR request contains either a cookie or a filename. Either mean
This identifies the last name I got from you, give me the next one.
Is there something that makes that interface problematic?
Another client may have removed the name and re-added a new file with
that name. At this point
On Sunday April 8, [EMAIL PROTECTED] wrote:
On Sun, 8 April 2007 11:11:20 -0700, H. Peter Anvin wrote:
Well, the question is if you can keep the seekdir/telldir cookie around
as a pointer -- preferrably in userspace, of course. You would
presumably garbage-collect them on closedir()
On 4/10/07, Neil Brown [EMAIL PROTECTED] wrote:
2/ Some data structure using an ordered search key that is based on
the filename (e.g. a B-tree with a search key that is a hash of the
filename).
In the first case, you just use a fixed opaque cookie for location in
a directory.
In the second
On Wed, 2007-04-11 at 07:37 +1000, Neil Brown wrote:
On Tuesday April 10, [EMAIL PROTECTED] wrote:
On Wed, 2007-04-11 at 07:12 +1000, Neil Brown wrote:
Is there something that makes that interface problematic?
File deletions...
How are they a problem ?
There are only two ways
On Tuesday April 10, [EMAIL PROTECTED] wrote:
On Wed, 2007-04-11 at 07:37 +1000, Neil Brown wrote:
On Tuesday April 10, [EMAIL PROTECTED] wrote:
On Wed, 2007-04-11 at 07:12 +1000, Neil Brown wrote:
Is there something that makes that interface problematic?
File deletions...
On Wed, 2007-04-11 at 08:33 +1000, Neil Brown wrote:
A READDIR (aka getdents2) should take a directory handle, a cookie,
and a filename, and should return filenames and cookies. The
cookies may all be identical or may not. The filename might be used
by the filesystem, or it might
In article [EMAIL PROTECTED] you wrote:
Otherwise, the client would have to cache _all_ previous READDIR results
since the last opendir()/rewinddir() in order to be able to do its own
loop detection and that will obviously never scale for large directories
or for directories that change
On Mon, 2007-04-09 at 18:34 +0200, Jan Engelhardt wrote:
> On Apr 9 2007 10:03, Trond Myklebust wrote:
>
> >In practice, though, this sort of behaviour has to be managed carefully
> >by the server. Forcing a client to re-read the entire contents of the
> >directory doesn't really scale too
On Apr 9 2007 10:03, Trond Myklebust wrote:
>In practice, though, this sort of behaviour has to be managed carefully
>by the server. Forcing a client to re-read the entire contents of the
>directory doesn't really scale too well...
What does the spec (readdir, and NFS READDIR) say about
On Mon, 2007-04-09 at 09:19 -0400, Theodore Tso wrote:
> On Mon, Apr 09, 2007 at 08:31:37AM -0400, Trond Myklebust wrote:
> > On Mon, 2007-04-09 at 13:09 +0200, Jörn Engel wrote:
> > > That surely doesn't make life any easier for filesystem developers, I
> > > agree. From that point of view, all
On Mon, Apr 09, 2007 at 08:31:37AM -0400, Trond Myklebust wrote:
> On Mon, 2007-04-09 at 13:09 +0200, Jörn Engel wrote:
> > That surely doesn't make life any easier for filesystem developers, I
> > agree. From that point of view, all telldir cookies should end their
> > life at closedir time.
Jörn Engel <[EMAIL PROTECTED]> writes:
> On Sun, 8 April 2007 21:44:26 -0400, Theodore Tso wrote:
>>
>> Well, Joern thought that rm -rf might relying on the telldir cookie
>> being valid in precisely that circumstance. If that is true, I'd
>> argue that this is a BUG in GNU coreutils that
On Mon, 2007-04-09 at 13:09 +0200, Jörn Engel wrote:
> That surely doesn't make life any easier for filesystem developers, I
> agree. From that point of view, all telldir cookies should end their
> life at closedir time. For "rm -r" it would be sufficient if the nfs
> client simply didn't
On Mon, 2007-04-09 at 13:09 +0200, Jörn Engel wrote:
> That surely doesn't make life any easier for filesystem developers, I
> agree. From that point of view, all telldir cookies should end their
> life at closedir time. For "rm -r" it would be sufficient if the nfs
> client simply didn't
On Sun, 8 April 2007 21:44:26 -0400, Theodore Tso wrote:
>
> Well, Joern thought that rm -rf might relying on the telldir cookie
> being valid in precisely that circumstance. If that is true, I'd
> argue that this is a BUG in GNU coreutils that should be fixed...
I heard it and accepted that
On Sun, 8 April 2007 21:44:26 -0400, Theodore Tso wrote:
Well, Joern thought that rm -rf might relying on the telldir cookie
being valid in precisely that circumstance. If that is true, I'd
argue that this is a BUG in GNU coreutils that should be fixed...
I heard it and accepted that claim
On Mon, 2007-04-09 at 13:09 +0200, Jörn Engel wrote:
That surely doesn't make life any easier for filesystem developers, I
agree. From that point of view, all telldir cookies should end their
life at closedir time. For rm -r it would be sufficient if the nfs
client simply didn't seekdir at
On Mon, 2007-04-09 at 13:09 +0200, Jörn Engel wrote:
That surely doesn't make life any easier for filesystem developers, I
agree. From that point of view, all telldir cookies should end their
life at closedir time. For rm -r it would be sufficient if the nfs
client simply didn't seekdir at
Jörn Engel [EMAIL PROTECTED] writes:
On Sun, 8 April 2007 21:44:26 -0400, Theodore Tso wrote:
Well, Joern thought that rm -rf might relying on the telldir cookie
being valid in precisely that circumstance. If that is true, I'd
argue that this is a BUG in GNU coreutils that should be
On Mon, Apr 09, 2007 at 08:31:37AM -0400, Trond Myklebust wrote:
On Mon, 2007-04-09 at 13:09 +0200, Jörn Engel wrote:
That surely doesn't make life any easier for filesystem developers, I
agree. From that point of view, all telldir cookies should end their
life at closedir time. For rm -r
On Mon, 2007-04-09 at 09:19 -0400, Theodore Tso wrote:
On Mon, Apr 09, 2007 at 08:31:37AM -0400, Trond Myklebust wrote:
On Mon, 2007-04-09 at 13:09 +0200, Jörn Engel wrote:
That surely doesn't make life any easier for filesystem developers, I
agree. From that point of view, all telldir
On Apr 9 2007 10:03, Trond Myklebust wrote:
In practice, though, this sort of behaviour has to be managed carefully
by the server. Forcing a client to re-read the entire contents of the
directory doesn't really scale too well...
What does the spec (readdir, and NFS READDIR) say about duplicate
On Mon, 2007-04-09 at 18:34 +0200, Jan Engelhardt wrote:
On Apr 9 2007 10:03, Trond Myklebust wrote:
In practice, though, this sort of behaviour has to be managed carefully
by the server. Forcing a client to re-read the entire contents of the
directory doesn't really scale too well...
1 - 100 of 130 matches
Mail list logo
