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

Re: Max Mount Count

Heinz writes:
> 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
>    *or*
>  - of a physical volume in order to make sure that reads physically
>    come from disk afterwards.

I'm not sure I agree with this argument:
- if the metadata is being written by the kernel and read by user-space
  (only snapshot metadata for now) then fsync_dev() should be enough to
  flush it to the disk so that user-space is assured it is valid.
- if metadata is being written by user space (VGDA currently), then it
  doesn't matter what the kernel sees, because it is not reading this
  data.  If the kernel DID need to read data written by user space, then
  invalidate_buffers() would only need to be run on specific PVs, and not
  all PVs in the system.
- if metadata is being written by both user space AND the kernel (I
  don't think this happens, but) then you are asking for corruption
  at some stage or another.

> 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.

Yes, this has been added to ext3 for 2.4, but I think that is a separate
issue from pvscan/vgscan calling invalidate_buffers() on ALL devices.

Cheers, Andreas.

> On Sat, Jun 09, 2001 at 02:58:04PM +1000, Andrew Morton wrote:
> > Stephen Tweedie wrote:
> > > 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.
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

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