[lkml]   [2002]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: invalidate_inode_pages in 2.5.32/3
On Thursday 12 September 2002 23:38, Andrew Morton wrote:
> Daniel Phillips wrote:
> >
> > ...
> > > Is it not possible to co-opt a user process to perform the
> > > invalidation? Just
> > >
> > > inode->is_kaput = 1;
> > >
> > > in rpciod?
> >
> > There must be a way. The key thing the VM needs to provide, and doesn't
> > now, is a function callable by the rpciod that will report to the caller
> > whether it was able to complete the invalidation without blocking. (I
> > think I'm just rephrasing someone's earlier suggestion here.)
> >
> > I'm now thinking in general terms about how to concoct a mechanism
> > that lets rpciod retry the invalidation later, for all those that turn
> > out to be blocking. For example, rpciod could just keep a list of
> > all pending invalidates and retry each inode on the list every time
> > it has nothing to do. This is crude and n-squarish, but it would
> > work. Maybe it's efficient enough for the time being. At least it's
> > correct, which would be a step forward.
> rpciod is the wrong process to be performing this operation. I'd suggest
> the userspace process which wants to read the directory be used for this.

It's not just directories as I understand it, it's also any file that's
locked or unlocked.

If we make userspace do it, we need an interface. Is there

> > Did you have some specific mechanism in mind?
> Testing mapping->nrpages will tell you if the invalidation was successful.

That's nice, so may be no need for a new flavor of invalidate_inode_pages
to write, but what I was really talking about is what should be done
after discovering it failed.

Another thing: we only care about pages that were in the mapping at the
time of the original invalidate attempt. Coming back and invalidating
a bunch of pages that were already properly re-read from the server,
just to get those few we missed on the first attempt would be, in a
word, horrible.

This one is harder than it first seems. It's worth putting in the
effort to do the job correctly though. The current arrangement is,
err, unreliable.

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

 \ /
  Last update: 2005-03-22 13:28    [W:0.065 / U:3.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site