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

Re: Max Mount Count



On Mon, Jun 11, 2001 at 09:31:52PM -0600, Andreas Dilger wrote:
> 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.

The LVM kernel only writes snapshot data and metadata to disk using kiobufs.
Therefore no fsync_dev is necessary.

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

Correct. This will be true for post 1.0 LVM when we read metadata in the kernel.

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

No, this doesn't happen.

The point behind the "...make sure that reads physically come from disk
afterwards" is to make sure that the LVM library doesn't get data from
the Linux buffer/page cache in order to recognize that block
devices have been unhooked or are otherwise not accessable any longer.
IOW: block devices should be at least physically readable when the
     VGDA is retrieved.

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

Yes, it is seperate.
Just wanted to address *all* syncs within the LVM kernel code.

Regards,
Heinz    -- The LVM Guy --


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

*** 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
                                                  Germany
Mauelshagen Sistina com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-





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