Chris Mason wrote:
>
> On Mon, 1 May 2000, Stephen C. Tweedie wrote:
>
> > Hi,
> >
> > On Fri, Apr 28, 2000 at 11:57:23AM -0700, Chris Mason wrote:
> > >
> > > The fs/inode.c and fs.h changes allow the FS to provide a dirty_inode
> > > call. I'm using this to log the inodes instead of allowing them to hit
> > > the dirty list, which saves me from deadlocks when try_to_free_pages
> > > forces a flush of the dirty inode list.
> >
> > Isn't this going to be very inefficient when we are constantly
> > updating the inode's atime for a series of file reads? I'd have
> > thought that we'd _want_ to defer the writing of the inode as
> > long as possible in that case, precisely to avoid logging the
> > inode too many times.
Let the FS do the deferment (if it chooses to manage that) is the point. Yes,
the FS should defer it, but not past the point that the FS writes it to disk
anyway because it is in a buffer that is being written.
> In other words, I'm not thrilled with this either ;-) Perhaps we could
> get around the deadlock by allowing only one person to call prune_icache
> at once, so that callers of try_to_free_pages will skip the inode flush if
> another proc is already doing it.
That won't cure the deferment past write to disk performance issue. Any FS
that puts stat() data in directory entries probably has the same problem. Or do
I miss an applicable coding model here somewhere?
Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:08 EST