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

Re: Max Mount Count

Hi Andrew,

in regard to your question "What the heck is LVM trying to do?" at the end
of your mail:

LVM only invalidates the buffers
 - of a logical volume in case it *removes* it
 - of a physical volume in order to make sure that reads physically
   come from disk afterwards.

In case it creates a snapshot logical volume it syncs the buffers of the
original logical volume and calls the fsync_dev_lockfs() function
(in case LVM_VFS_ENHANCEMENT has been defined) in order to set
the filesystem to a sane state and lock it. The (journaled) filesystem should
make sure in this call, that after a return form it and a call to unlockfs()
from within the LVM driver *no* writes get queued to the snapshot, because
snapshots are readonly so far.

Heinz    -- The LVM Guy --

On Sat, Jun 09, 2001 at 02:58:04PM +1000, Andrew Morton wrote:
> "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.

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***


Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
Mauelshagen Sistina com                           +49 2626 141200
                                                       FAX 924446

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