[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Max Mount Count



"Stephen C. Tweedie" wrote:
> 
> Hi,
> 
> On Fri, Jun 08, 2001 at 10:20:52AM -0700, Jay Weber wrote:
> 
> > I'm using the same generic lockfs/unlockfs() wrapper code as supplied with
> > 2.4 LVM patches for doing those bits.  I believe Andrea Arcangeli has
> > included them in his 2.2 tree also for use with reiserfs.
> >
> > Cut&Paste below (pretty small):
> [deleted]
> 
> Looks sane.
> 
> > Yeah, I'm using the following which AFAIK seems to cover the occurances
> > that LVM surfaced.  I can run multiple pvscans, etc for hours without
> > generating the refile buffers at least.
> 
> I'll apply to 2.2.  For 2.4, we need to take appropriate locking
> before we can make such a test.
> 
> Andrew, what do you think?  I'm tempted to solve this by taking the
> lru_list_lock and bumping b_count when adding the journal_head to an
> existing buffer_head.  That would certainly protect against buffer
> invalidation and try_to_free_buffers, without requiring us to
> hard-code the protection of journaled buffers into the rest of the VM.

b_count is elevated whenever the buffer has an attached journal_head,
so invalidate_buffers won't touch them.  We can say that for uniprocessors.

And yes, to be safe on SMP we'd need to take lru_list_lock to avoid
racing with __invalidate_buffers().  But that won't protect us from
the buffer being invalidated a few nanoseconds *before* we try to
add a journal_head to the buffer_head.

The same applies to try_to_free_buffers(): once we've decided to
attach a journal_head to a buffer, we *cant* have try_to_free_buffers()
or __invalidate_buffers() come along and turn the buffer_head into
thin air before we've done the attachment.

So it's a bug for us to call journal_add_journal_head() on a
buffer_head which has a zero b_count.  I'm pretty sure we're
not doing that now, but I'll make sure today.

Once that is done, journalling is safe from __invalidate_buffers(),
because we always carry an elevated b_count on a buffer which
either has, or is destined to have, a journal_head. And when
we detach a journal_head and drop b_count we never look at the
buffer again.

Make sense?

It does leave one little question open:

> However, I'm still nervous: journaling can keep buffers around for
> quite a while for various reasons.  WHY does LVM want to invalidate
> buffers?  I'm scared that by "fixing" this we actually mask a deeper
> problem.  By causing journaled buffers to remain in the system after
> an invalidate, are we going to violate some assumption that LVM is
> making about its ability to flush things from the kernel?

What the heck is LVM trying to do?  We've basically
subverted it via the above proposal.  If Heinz can give us
an understanding of what, at a higher level, LVM is trying
to achieve by calling invalidate_bufers(), we can decide on
how best to respond to it.   The best way will probably be
to lock the journal for updates, flush it and wait for LVM
to unlock again.  That will require a new interface.





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]