[linux-lvm] snapshot of Reiserfs

[linux-lvm] snapshot of Reiserfs

[lvm]

I am using LVM 0.9.1 beta 4 on Linux 2.4.1 with Reiserfs.

Snapshots created when the filesystem is active cannot be mounted.
If I `umount' the filesystem before creating the snapshot, all is well.

I searched the mailing list archives and found a thread that dealt
with this problem on Linux 2.4.0 by applying a patch that flushed
the buffers before creating the snapshot:

  http://lists.sistina.com/pipermail/linux-lvm/2000-December/005512.html

This is clearly the problem I'm seeing.

Is there a comparable patch for 2.4.1?

Will the fix become "standard" in 2.4.2
so that patching is no longer necessary?

Larry

Re: [linux-lvm] snapshot of Reiserfs

[Joe Thornber]

On Mon, Feb 19, 2001 at 11:11:28AM -0500, lvm@winux.com wrote:
> I am using LVM 0.9.1 beta 4 on Linux 2.4.1 with Reiserfs.
> 
> Snapshots created when the filesystem is active cannot be mounted.
> If I `umount' the filesystem before creating the snapshot, all is well.
> 
> I searched the mailing list archives and found a thread that dealt
> with this problem on Linux 2.4.0 by applying a patch that flushed
> the buffers before creating the snapshot:
> 
>   http://lists.sistina.com/pipermail/linux-lvm/2000-December/005512.html
> 
> This is clearly the problem I'm seeing.
> 
> Is there a comparable patch for 2.4.1?

Try the PATCHES/linux-2.4.0-test10-VFS-lock.patch in the latest
release, it should apply ok.

- Joe

Re: [linux-lvm] snapshot of Reiserfs

[Joe Thornber]

On Mon, Feb 19, 2001 at 06:04:56PM +0100, Christoph Hellwig wrote:
> On Mon, Feb 19, 2001 at 04:12:26PM +0000, Joe Thornber wrote:
> > > Is there a comparable patch for 2.4.1?
> > 
> > Try the PATCHES/linux-2.4.0-test10-VFS-lock.patch in the latest
> > release, it should apply ok.
> 
> At least the write_super_lockfs super_operations _is_ already in 2.4.1.

OK, we'll make a new patch for the next beta release (due out in the
next couple of days).

- Joe

Re: [linux-lvm] snapshot of Reiserfs

[Christoph Hellwig]

On Mon, Feb 19, 2001 at 04:12:26PM +0000, Joe Thornber wrote:
> > Is there a comparable patch for 2.4.1?
> 
> Try the PATCHES/linux-2.4.0-test10-VFS-lock.patch in the latest
> release, it should apply ok.

At least the write_super_lockfs super_operations _is_ already in 2.4.1.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: [lvm-devel] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com

[Andrea Arcangeli]

On Tue, Feb 20, 2001 at 10:49:07PM +0000, Heinz Mauelshagen wrote:
> 
> Hi all,
> 
> a tarball of the Linux Logical Volume Manager 0.9.1 Beta 5 is available now at
> 
>    <http://www.sistina.com/>
> 
> for download (Follow the "LVM download page" link).
> 
> This release fixes several bugs.
> See the CHANGELOG file contained in the tarball for further information.
> 
> A change in the i/o protocoll version *forces* you to update
> the driver as well.
> Follow instructions in PATCHES/README to achieve this please.
> 
> 
> Please help us to stabilize for 0.9.1 ASAP and test is as much as possible!
> Feed back related information to <linux-lvm@sistina.com>.

The bheads in the lv_t is the wrong way to go, I just wrote an alternate patch
for rawio that keeps the bh inside the kiovec, not in the lv, this also
imrproves rawio performance in general (such allocation deallocation flood was
wasteful). No a single change is required at the lvm layer, all the changes lives in
the kiobuf layer. It's tested and it works for me.

diff -urN rawio-ref/fs/buffer.c rawio/fs/buffer.c
--- rawio-ref/fs/buffer.c	Tue Feb 20 23:17:10 2001
+++ rawio/fs/buffer.c	Tue Feb 20 23:17:27 2001
@@ -1240,6 +1240,29 @@
 	wake_up(&buffer_wait);
 }
 
+int alloc_kiobuf_bhs(struct kiobuf * kiobuf)
+{
+	int i, j;
+
+	for (i = 0; i < KIO_MAX_SECTORS; i++)
+		if (!(kiobuf->bh[i] = get_unused_buffer_head(0))) {
+			for (j = 0; j < i; j++)
+				put_unused_buffer_head(kiobuf->bh[j]);
+			wake_up(&buffer_wait);
+			return -ENOMEM;
+		}
+	return 0;
+}
+
+void free_kiobuf_bhs(struct kiobuf * kiobuf)
+{
+	int i;
+
+	for (i = 0; i < KIO_MAX_SECTORS; i++)
+		put_unused_buffer_head(kiobuf->bh[i]);
+	wake_up(&buffer_wait);
+}
+
 static void end_buffer_io_async(struct buffer_head * bh, int uptodate)
 {
 	unsigned long flags;
@@ -1333,10 +1356,8 @@
 			iosize = 0;
 		}
 		
-		put_unused_buffer_head(tmp);
 		iosize += size;
 	}
-	wake_up(&buffer_wait);
 	
 	dprintk ("do_kio end %d %d\n", iosize, err);
 	
@@ -1390,7 +1411,7 @@
 	int		i;
 	int		bufind;
 	int		pageind;
-	int		bhind;
+	int		bhind, kiobuf_bh_nr;
 	int		offset;
 	unsigned long	blocknr;
 	struct kiobuf *	iobuf = NULL;
@@ -1422,6 +1443,7 @@
 	 */
 	bufind = bhind = transferred = err = 0;
 	for (i = 0; i < nr; i++) {
+		kiobuf_bh_nr = 0;
 		iobuf = iovec[i];
 		err = setup_kiobuf_bounce_pages(iobuf, GFP_USER);
 		if (err) 
@@ -1444,12 +1466,8 @@
 
 			while (length > 0) {
 				blocknr = b[bufind++];
-				tmp = get_unused_buffer_head(0);
-				if (!tmp) {
-					err = -ENOMEM;
-					goto error;
-				}
-				
+				tmp = iobuf->bh[kiobuf_bh_nr++];
+
 				tmp->b_dev = B_FREE;
 				tmp->b_size = size;
 				tmp->b_data = (char *) (page + offset);
@@ -1460,7 +1478,8 @@
 				if (rw == WRITE) {
 					set_bit(BH_Uptodate, &tmp->b_state);
 					set_bit(BH_Dirty, &tmp->b_state);
-				}
+				} else
+					clear_bit(BH_Uptodate, &tmp->b_state);
 
 				dprintk ("buffer %d (%d) at %p\n", 
 					 bhind, tmp->b_blocknr, tmp->b_data);
@@ -1478,7 +1497,7 @@
 						transferred += err;
 					else
 						goto finished;
-					bhind = 0;
+					kiobuf_bh_nr = bhind = 0;
 				}
 				
 				if (offset >= PAGE_SIZE) {
@@ -1506,17 +1525,6 @@
 	if (transferred)
 		return transferred;
 	return err;
-
- error:
-	/* We got an error allocation the bh'es.  Just free the current
-           buffer_heads and exit. */
-	for (i = 0; i < bhind; i++)
-		put_unused_buffer_head(bh[i]);
-	wake_up(&buffer_wait);
-
-	clear_kiobuf_bounce_pages(iobuf);
-
-	goto finished;
 }
 
 /*
diff -urN rawio-ref/fs/iobuf.c rawio/fs/iobuf.c
--- rawio-ref/fs/iobuf.c	Tue Feb 20 23:17:10 2001
+++ rawio/fs/iobuf.c	Tue Feb 20 23:17:24 2001
@@ -41,6 +41,11 @@
 		iobuf->pagelist   = iobuf->page_array;
 		iobuf->maplist    = iobuf->map_array;
 		iobuf->bouncelist = iobuf->bounce_array;
+		if (alloc_kiobuf_bhs(iobuf)) {
+			kmem_cache_free(kiobuf_cachep, iobuf);
+			free_kiovec(i, bufp);
+			return -ENOMEM;
+		}
 		*bufp++ = iobuf;
 	}
 	
@@ -73,6 +78,7 @@
 		if (iobuf->array_len > KIO_STATIC_PAGES) {
 			kfree (iobuf->pagelist);
 		}
+		free_kiobuf_bhs(iobuf);
 		kmem_cache_free(kiobuf_cachep, bufp[i]);
 	}
 }
diff -urN rawio-ref/include/linux/iobuf.h rawio/include/linux/iobuf.h
--- rawio-ref/include/linux/iobuf.h	Tue Feb 20 23:17:10 2001
+++ rawio/include/linux/iobuf.h	Tue Feb 20 23:17:24 2001
@@ -50,6 +50,7 @@
 	unsigned long	page_array[KIO_STATIC_PAGES];
 	struct page *	map_array[KIO_STATIC_PAGES];
 	unsigned long	bounce_array[KIO_STATIC_PAGES];
+	struct buffer_head *bh[KIO_MAX_SECTORS];
 };
 
 
@@ -67,6 +68,8 @@
 int	setup_kiobuf_bounce_pages(struct kiobuf *, int gfp_mask);
 void	clear_kiobuf_bounce_pages(struct kiobuf *);
 void	kiobuf_copy_bounce(struct kiobuf *, int direction, int max);
+extern int alloc_kiobuf_bhs(struct kiobuf *);
+extern void free_kiobuf_bhs(struct kiobuf *);
 
 /* Direction codes for kiobuf_copy_bounce: */
 enum {



I didn't had much time to look into beta5 yet but I can't see why you changed
the protocol to 11. There's no breakage between beta4 and beta5 in the
datastructures shared with userspace.  I don't like gratuitous API breakage.

Just as reminer the hardsectsize fix isn't yet merged in beta5.

Andrea

[linux-lvm] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com

[Heinz J. Mauelshagen]

Hi all,

a tarball of the Linux Logical Volume Manager 0.9.1 Beta 5 is available now at

   <http://www.sistina.com/>

for download (Follow the "LVM download page" link).

This release fixes several bugs.
See the CHANGELOG file contained in the tarball for further information.

A change in the i/o protocoll version *forces* you to update
the driver as well.
Follow instructions in PATCHES/README to achieve this please.


Please help us to stabilize for 0.9.1 ASAP and test is as much as possible!
Feed back related information to <linux-lvm@sistina.com>.

Thanks a lot for your support of LVM.

-- 

Regards,
Heinz    -- The LVM Guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

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

Re: [lvm-devel] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com

[Andreas Dilger]

Andrea writes:
> On Tue, Feb 20, 2001 at 10:49:07PM +0000, Heinz Mauelshagen wrote:
> > A change in the i/o protocoll version *forces* you to update
> > the driver as well.
> 
> I didn't had much time to look into beta5 yet but I can't see why you changed
> the protocol to 11. There's no breakage between beta4 and beta5 in the
> datastructures shared with userspace.  I don't like gratuitous API breakage.

The reason why the IOP was changed was because the VG_CREATE ioctl now
depends on the vg_number in the supplied vg_t to determine which VG minor
number to use.  The old interface used the minor number of the opened
device inode, but for devfs the device inodes don't exist until the VG
is created...  If you run an older kernel with new tools, you can only
use the first VG.

I suggested reverting this change for the current release, and only fixing
the LVM devfs code (which is probably still broken in other ways).  Heinz
decided to update the IOP instead.  Note that with the new library build,
it is possible to have multiple IOP tools installed at the same time, and
the correct ones are chosen at runtime based on the kernel IOP.

Cheers, Andreas
-- 
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

Re: [lvm-devel] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com

[Andrea Arcangeli]

On Tue, Feb 20, 2001 at 05:31:25PM -0700, Andreas Dilger wrote:
> The reason why the IOP was changed was because the VG_CREATE ioctl now
> depends on the vg_number in the supplied vg_t to determine which VG minor
> number to use.  The old interface used the minor number of the opened
> device inode, but for devfs the device inodes don't exist until the VG
> is created...  If you run an older kernel with new tools, you can only
> use the first VG.

Ah, I was reading the patch incidentally against 2.2 patch where devfs support
is not included, so I wasn't thinking the devfs way ;). Thanks for the
explanation.

I assume it's not possible to mknod on top of devfs.  So then we could use a
temporary device in /var/tmp or whatever for that.  However those workarounds
tends to be ugly.

Probably the best way to preserve the IOP that I recommend for beta6 is to add
a new ioctl to the VG chardevice.  Rename VG_CREATE to VG_CREATE_OLD.
VG_CREATE_OLD is a wrapper that calculates the minor number from the inode and
then fallbacks into VG_CREATE, and the new VG_CREATE is the one that gets
the minor of the vg from userspace.

Either ways we don't break backwards compatibilty across 0.9* cycle.

If there would been a strong reason and it would be a mess to provide backwards
compatibilty I would of course agree to raise at IOP 11, but just to avoid a
few lines of code for a wrapper or a temporary mknod on /tmp for a devfs-only
fix, I think it worth to preserve IOP 10.

Andrea

Re: [lvm-devel] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com

[Richard Gooch]

Andrea Arcangeli writes:
> On Tue, Feb 20, 2001 at 05:31:25PM -0700, Andreas Dilger wrote:
> > The reason why the IOP was changed was because the VG_CREATE ioctl now
> > depends on the vg_number in the supplied vg_t to determine which VG minor
> > number to use.  The old interface used the minor number of the opened
> > device inode, but for devfs the device inodes don't exist until the VG
> > is created...  If you run an older kernel with new tools, you can only
> > use the first VG.
> 
> Ah, I was reading the patch incidentally against 2.2 patch where devfs support
> is not included, so I wasn't thinking the devfs way ;). Thanks for the
> explanation.
> 
> I assume it's not possible to mknod on top of devfs.  So then we
> could use a temporary device in /var/tmp or whatever for that.
> However those workarounds tends to be ugly.

You definately can mknod(2) on devfs.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

[linux-lvm] snapshot of Reiserfs

[lvm, lvm]

Heinz J. Mauelshagen writes:
> ... Linux Logical Volume Manager 0.9.1 Beta 5 is available now ...
> ...
> Please help us to stabilize for 0.9.1 ASAP and test is as much as possible!

I am using LVM 0.9.1 beta 5 on Linux 2.4.1 with Reiserfs.
I have applied both of the following patches:

0.9.1_beta5/PATCHES/lvm-0.9.1_beta5-2.4.1.patch
0.9.1_beta5/PATCHES/linux-2.4.1-VFS-lock.patch

Snapshots created when the filesystem is active cannot be mounted.
If I `umount' the filesystem before creating the snapshot, all is well.

Larry

Re: [linux-lvm] snapshot of Reiserfs

[Patrick Caulfield]

On Tue, Feb 20, 2001 at 11:19:51PM -0500, lvm@winux.com wrote:
> Heinz J. Mauelshagen writes:
> > ... Linux Logical Volume Manager 0.9.1 Beta 5 is available now ...
> > ...
> > Please help us to stabilize for 0.9.1 ASAP and test is as much as possible!
> 
> I am using LVM 0.9.1 beta 5 on Linux 2.4.1 with Reiserfs.
> I have applied both of the following patches:
> 
> 0.9.1_beta5/PATCHES/lvm-0.9.1_beta5-2.4.1.patch
> 0.9.1_beta5/PATCHES/linux-2.4.1-VFS-lock.patch
> 
> Snapshots created when the filesystem is active cannot be mounted.
> If I `umount' the filesystem before creating the snapshot, all is well.

Did you remember to uncomment LVM_VFS_ENHANCEMENT in lvm.c ?

patrick

Re: [linux-lvm] snapshot of Reiserfs

[lvm]

Patrick Caulfield writes:
> From: Patrick Caulfield <caulfield@sistina.com>
> Sender: linux-lvm-admin@sistina.com
> To: linux-lvm@sistina.com
> Subject: Re: [linux-lvm] snapshot of Reiserfs
> Date: Wed, 21 Feb 2001 08:59:59 +0000
> 
> On Tue, Feb 20, 2001 at 11:19:51PM -0500, lvm@winux.com wrote:
> > Heinz J. Mauelshagen writes:
> > > ... Linux Logical Volume Manager 0.9.1 Beta 5 is available now ...
> > > ...
> > > Please help us to stabilize for 0.9.1 ASAP and test is as much as possible!
> > 
> > I am using LVM 0.9.1 beta 5 on Linux 2.4.1 with Reiserfs.
> > I have applied both of the following patches:
> > 
> > 0.9.1_beta5/PATCHES/lvm-0.9.1_beta5-2.4.1.patch
> > 0.9.1_beta5/PATCHES/linux-2.4.1-VFS-lock.patch
> > 
> > Snapshots created when the filesystem is active cannot be mounted.
> > If I `umount' the filesystem before creating the snapshot, all is well.
> 
> Did you remember to uncomment LVM_VFS_ENHANCEMENT in lvm.c ?
> 
> patrick

Bingo!  That was the problem!  Many thanks!

Shouldn't that change be included in the VFS-lock patch?

In fact, why are these separate patches?  Shouldn't they
eventually be "the standard" and find their way into the
stock kernel?  It's arguably the correct behavior.

Larry

Re: [linux-lvm] snapshot of Reiserfs

[Patrick Caulfield]

On Wed, Feb 21, 2001 at 09:04:32AM -0500, lvm@winux.com wrote:
> Patrick Caulfield writes:
> > From: Patrick Caulfield <caulfield@sistina.com>
> > Sender: linux-lvm-admin@sistina.com
> > To: linux-lvm@sistina.com
> > Subject: Re: [linux-lvm] snapshot of Reiserfs
> > Date: Wed, 21 Feb 2001 08:59:59 +0000
> > 
> > On Tue, Feb 20, 2001 at 11:19:51PM -0500, lvm@winux.com wrote:
> > > Heinz J. Mauelshagen writes:
> > > > ... Linux Logical Volume Manager 0.9.1 Beta 5 is available now ...
> > > > ...
> > > > Please help us to stabilize for 0.9.1 ASAP and test is as much as possible!
> > > 
> > > I am using LVM 0.9.1 beta 5 on Linux 2.4.1 with Reiserfs.
> > > I have applied both of the following patches:
> > > 
> > > 0.9.1_beta5/PATCHES/lvm-0.9.1_beta5-2.4.1.patch
> > > 0.9.1_beta5/PATCHES/linux-2.4.1-VFS-lock.patch
> > > 
> > > Snapshots created when the filesystem is active cannot be mounted.
> > > If I `umount' the filesystem before creating the snapshot, all is well.
> > 
> > Did you remember to uncomment LVM_VFS_ENHANCEMENT in lvm.c ?
> > 
> > patrick
> 
> Bingo!  That was the problem!  Many thanks!
> 
> Shouldn't that change be included in the VFS-lock patch?

It complicates the order of applying them but it's a fair point.
 
> In fact, why are these separate patches?  Shouldn't they
> eventually be "the standard" and find their way into the
> stock kernel?  It's arguably the correct behavior.

That is the intension. The patch is Chris Mason's and I beleive
he is trying to get it into the kernel. Heinz emailed him about
it recently, I don't know if he has had any reply yet.

Patrick

Re: [linux-lvm] snapshot of Reiserfs

[Chris Mason]

On Wednesday, February 21, 2001 02:11:20 PM +0000 Patrick Caulfield
<caulfield@sistina.com> wrote:

[ non-intuitive snapshot patches for reiserfs ]
>  
>> In fact, why are these separate patches?  Shouldn't they
>> eventually be "the standard" and find their way into the
>> stock kernel?  It's arguably the correct behavior.
> 
> That is the intension. The patch is Chris Mason's and I beleive
> he is trying to get it into the kernel. Heinz emailed him about
> it recently, I don't know if he has had any reply yet.
> 

We can probably talk Alan into putting it in the ac series, but I'm not
expecting Linus to take it yet.  I'll send it along for 2.4.3preX though
(once 2.4.2 comes out), maybe we'll get lucky ;-)

Do you want the patch I send to turn on the VFS_ENHANCEMENT #define in
lvm.c?

-chris

Re: [linux-lvm] snapshot of Reiserfs

[lvm]

Chris Mason writes:
> Do you want the patch I send to turn on the VFS_ENHANCEMENT #define in lvm.c?

That seems to make sense.  After all, the purpose of the patch is to
add that support.  Leaving it disabled after applying the patch is
counterintuitive.

Larry

Re: [linux-lvm] snapshot of Reiserfs

[Patrick Caulfield]

On Wed, Feb 21, 2001 at 10:34:33AM -0500, Chris Mason wrote:
> 
> 
> On Wednesday, February 21, 2001 02:11:20 PM +0000 Patrick Caulfield
> <caulfield@sistina.com> wrote:
> 
> [ non-intuitive snapshot patches for reiserfs ]
> >  
> >> In fact, why are these separate patches?  Shouldn't they
> >> eventually be "the standard" and find their way into the
> >> stock kernel?  It's arguably the correct behavior.
> > 
> > That is the intension. The patch is Chris Mason's and I beleive
> > he is trying to get it into the kernel. Heinz emailed him about
> > it recently, I don't know if he has had any reply yet.
> > 
> 
> We can probably talk Alan into putting it in the ac series, but I'm not
> expecting Linus to take it yet.  I'll send it along for 2.4.3preX though
> (once 2.4.2 comes out), maybe we'll get lucky ;-)

That sounds reasonable. With reiserfs and LVM in the kerel I thing there's a
good argument for making them work well together. :-)

 
> Do you want the patch I send to turn on the VFS_ENHANCEMENT #define in
> lvm.c?

I suppose it would be the easiest thing for users. Now LVM 0.9 is part of the
standard kernel it means the patches can be applied in any order, which was my
initial concern.


patrick

Re: [linux-lvm] snapshot of Reiserfs

[Andreas Dilger]

Patrick writes:
> On Tue, Feb 20, 2001 at 11:19:51PM -0500, lvm@winux.com wrote:
> > I am using LVM 0.9.1 beta 5 on Linux 2.4.1 with Reiserfs.
> > I have applied both of the following patches:
> > 
> > 0.9.1_beta5/PATCHES/lvm-0.9.1_beta5-2.4.1.patch
> > 0.9.1_beta5/PATCHES/linux-2.4.1-VFS-lock.patch
> > 
> > Snapshots created when the filesystem is active cannot be mounted.
> > If I `umount' the filesystem before creating the snapshot, all is well.
> 
> Did you remember to uncomment LVM_VFS_ENHANCEMENT in lvm.c ?

Given that the VFS support for the *unlockfs methods is included in 2.4.1,
this should probably become something like:

/* lvm_do_lv_create calls fsync_dev_lockfs()/unlockfs() */
#if LINUX_KERNEL_VERSION >= KERNEL_VERSION(2,4,1)
#define	LVM_VFS_ENHANCEMENT
#else
/* Need to apply a kernel patch to add lockfs/unlockfs VFS methods */
/* #define	LVM_VFS_ENHANCEMENT */
#endif

Also, if the sync_supers_lockfs() method is changed to call write_super()
if write_super_lockfs() doesn't exist, like:


 		lock_super(sb);
 		if (sb->s_dev && (!dev || dev == sb->s_dev))
-			if (sb->s_op && sb->s_op->write_super_lockfs)
-				sb->s_op->write_super_lockfs(sb);
+			if (sb->s_op) {
+				if (sb->s_op->write_super_lockfs)
+					sb->s_op->write_super_lockfs(sb);
+				else if (sb->s_op->write_super)
+					sb->s_op->write_super(sb);
+			}
 		unlock_super(sb);
	}


then in lvm_do_lv_create we only need to call either fsync_dev() OR
fsync_dev_lockfs(), instead of calling both like is currently done.

#ifdef	LVM_VFS_ENHANCEMENT
		/* VFS call to sync and lock the filesystem (if possible) */
		fsync_dev_lockfs(org->lv_dev);
#else
		/* sync the original logical volume */
		fsync_dev(org->lv_dev);
#endif

Cheers, Andreas
-- 
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

Re: [lvm-devel] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com

[Andrea Arcangeli]

On Wed, Feb 21, 2001 at 02:49:17PM +1100, Richard Gooch wrote:
> You definately can mknod(2) on devfs. [..]

So then why don't we simply create the VG ourself with the right minor number
and use it as we do without devfs? We'll still have a global 256 VG limit this
way but that's not a minor issue.

Andrea

Re: [lvm-devel] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com

[Richard Gooch]

[LVM list removed so I don't get the nastygram]
Andrea Arcangeli writes:
> On Wed, Feb 21, 2001 at 02:49:17PM +1100, Richard Gooch wrote:
> > You definately can mknod(2) on devfs. [..]
> 
> So then why don't we simply create the VG ourself with the right
> minor number and use it as we do without devfs? We'll still have a
> global 256 VG limit this way but that's not a minor issue.

Erm, that's a good question. Since I don't know the background to this
thread, can someone fill me in on what the problem/issue is?

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [linux-lvm] snapshot of Reiserfs

[Chris Mason]

On Wednesday, February 21, 2001 09:44:39 AM -0700 Andreas Dilger
<adilger@turbolinux.com> wrote:

> Given that the VFS support for the *unlockfs methods is included in 2.4.1,
> this should probably become something like:
> 
> /* lvm_do_lv_create calls fsync_dev_lockfs()/unlockfs() */
> #if LINUX_KERNEL_VERSION >= KERNEL_VERSION(2,4,1)
> #define	LVM_VFS_ENHANCEMENT
> #else
> /* Need to apply a kernel patch to add lockfs/unlockfs VFS methods */
> /* #define	LVM_VFS_ENHANCEMENT */
> #endif
> 

I like this idea.

> Also, if the sync_supers_lockfs() method is changed to call write_super()
> if write_super_lockfs() doesn't exist, like:
> 

The fsync_dev_lockfs call does this for us, if there is no
write_super_lockfs provided, fsync_dev_lockfs is effectively the same as
calling fsync_dev.

-chris

Re: [lvm-devel] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com

[Christoph Hellwig]

In article <20010221180035.N25927@athlon.random> you wrote:
> On Wed, Feb 21, 2001 at 02:49:17PM +1100, Richard Gooch wrote:
>> You definately can mknod(2) on devfs. [..]

> So then why don't we simply create the VG ourself with the right minor number
> and use it as we do without devfs? We'll still have a global 256 VG limit this
> way but that's not a minor issue.

Yes - that's how I did it in my inital LVM & devfs patches.
It would be really good to have something devfs-like just for LVM in
setups that don't use LVM, so we could avoid mounting root read/write
for device-creation.
One of the stronger points for a per-driver devfs, IHMO.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: [linux-lvm] snapshot of Reiserfs

[Andreas Dilger]

Chris, you write:
> On Wednesday, February 21, 2001 09:44:39 AM -0700 Andreas Dilger
> <adilger@turbolinux.com> wrote:
> > Given that the VFS support for the *unlockfs methods is included in 2.4.1,
> > this should probably become something like:
> > 
> > /* lvm_do_lv_create calls fsync_dev_lockfs()/unlockfs() */
> > #if LINUX_KERNEL_VERSION >= KERNEL_VERSION(2,4,1)
> > #define     LVM_VFS_ENHANCEMENT
> > #else
> > /* Need to apply a kernel patch to add lockfs/unlockfs VFS methods */
> > /* #define  LVM_VFS_ENHANCEMENT */
> > #endif
> > 
> 
> I like this idea.

Note that I thought the fsync_dev_lockfs() code was added to 2.4.1 when
reiserfs was added.  However, it appears that only the *lockfs pointers
were added to the super_operations, and the actual code that uses them
was NOT added.  This means we can't do the above until fsync_dev_lockfs()
is actually there.

> > Also, if the sync_supers_lockfs() method is changed to call write_super()
> > if write_super_lockfs() doesn't exist, like:
> 
> The fsync_dev_lockfs call does this for us, if there is no
> write_super_lockfs provided, fsync_dev_lockfs is effectively the same as
> calling fsync_dev.

Except that fsync_dev() calls the write_super() method, and fsync_dev_lockfs()
only calls the write_super_lockfs() method if it exists - it does not call
write_super() if write_super_lockfs() does not exist.  If it were changed as
I suggest, then the two would be the same.

Cheers, Andreas
-- 
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

Re: [linux-lvm] snapshot of Reiserfs

[Chris Mason]

On Wednesday, February 21, 2001 11:55:14 AM -0700 Andreas Dilger
<adilger@turbolinux.com> wrote:

>> > Given that the VFS support for the *unlockfs methods is included in
>> > 2.4.1, this should probably become something like:
>> > 
>> > /* lvm_do_lv_create calls fsync_dev_lockfs()/unlockfs() */
>> > #if LINUX_KERNEL_VERSION >= KERNEL_VERSION(2,4,1)
>> > #define     LVM_VFS_ENHANCEMENT
>> > #else
>> > /* Need to apply a kernel patch to add lockfs/unlockfs VFS methods */
>> > /* #define  LVM_VFS_ENHANCEMENT */
>> > #endif
>> > 
>> 
>> I like this idea.
> 
> Note that I thought the fsync_dev_lockfs() code was added to 2.4.1 when
> reiserfs was added.  However, it appears that only the *lockfs pointers
> were added to the super_operations, and the actual code that uses them
> was NOT added.  This means we can't do the above until fsync_dev_lockfs()
> is actually there.
> 
Yes, it would have been smarter for me to push for the entire lockfs patch
a long time ago.

>> > Also, if the sync_supers_lockfs() method is changed to call
>> > write_super() if write_super_lockfs() doesn't exist, like:
>> 
>> The fsync_dev_lockfs call does this for us, if there is no
>> write_super_lockfs provided, fsync_dev_lockfs is effectively the same as
>> calling fsync_dev.
> 
> Except that fsync_dev() calls the write_super() method, and
> fsync_dev_lockfs() only calls the write_super_lockfs() method if it
> exists - it does not call write_super() if write_super_lockfs() does not
> exist.  If it were changed as I suggest, then the two would be the same.

Hmmm, fsync_dev_lockfs should look like this:

+int fsync_dev_lockfs(kdev_t dev)
+{
+	sync_buffers(dev, 0);
+
+	lock_kernel();
+	sync_supers(dev);

        ^^^^^^^^^^^^^^^^^^

+	/* note, the FS might need to start transactions to 
+	** sync the inodes, or the quota, no locking until
+	** after these are done
+	*/
+	sync_inodes(dev);          
+	DQUOT_SYNC(dev);
+	/* if inodes or quotas could be dirtied during the
+	** sync_supers_lockfs call, the FS is responsible for getting
+	** them on disk, without deadlocking against the lock
+	*/
+	sync_supers_lockfs(dev) ;
+	unlock_kernel();
+
+	return sync_buffers(dev, 1) ;
+}
+

It is amost exactly a cut n' paste of fsync_dev, with an extra call to
sync_supers_lockfs.  It should do what fsync_dev does, even when there are
no sync_super_lockfs methods are provided.  The only reason I didn't just
call fsync_dev from fsync_dev_lockfs is because I wanted the sync_buffers
call to happen after the lockfs call ;-)

-chris

Re: [linux-lvm] snapshot of Reiserfs

[Andreas Dilger]

Chris Mason writes:
> Hmmm, fsync_dev_lockfs should look like this:
> 
> +int fsync_dev_lockfs(kdev_t dev)
> +{
> +	sync_buffers(dev, 0);
> +
> +	lock_kernel();
> +	sync_supers(dev);
>  	^^^^^^^^^^^^^^^^^^
> 
> +	/* note, the FS might need to start transactions to 
> +	** sync the inodes, or the quota, no locking until
> +	** after these are done
> +	*/
> +	sync_inodes(dev);          
> +	DQUOT_SYNC(dev);
> +	/* if inodes or quotas could be dirtied during the
> +	** sync_supers_lockfs call, the FS is responsible for getting
> +	** them on disk, without deadlocking against the lock
> +	*/
> +	sync_supers_lockfs(dev) ;
> +	unlock_kernel();
> +
> +	return sync_buffers(dev, 1) ;
> +}

Some overhead in calling sync_supers() and sync_supers_lockfs() because
they do both do the same list traversal.  Granted, on most systems the
total number of superblocks is small...  Last time I had a look at this,
I suggested that the sync_supers_lockfs() call be changed, namely that
it is illegal to call it with a zero "dev" parameter, otherwise you
will lock all filesystems and that may be a bad thing.  This simplifies
the code a bit.  If we also have it call write_super() if write_super_lockfs()
is missing, it is better yet.

> It is amost exactly a cut n' paste of fsync_dev, with an extra call to
> sync_supers_lockfs.  It should do what fsync_dev does, even when there are
> no sync_super_lockfs methods are provided.  The only reason I didn't just
> call fsync_dev from fsync_dev_lockfs is because I wanted the sync_buffers
> call to happen after the lockfs call ;-)

And the reason for this is?  The first call to sync_buffers doesn't wait
on completion (unlike the second sync_buffers call), so there is no
guarantee that they are all written out.

Cheers, Andreas
-- 
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

Re: [lvm-devel] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com

[Peter Samuelson]

[Christoph Hellwig]
> It would be really good to have something devfs-like just for LVM in
> setups that don't use LVM, so we could avoid mounting root read/write
                        ^^^devfs?
> for device-creation.

For most people, read/write access to /dev is rarely needed -- how
often do you create new VGs or LVs?  How often do you run MAKEDEV or
vgscan?  Sometimes you need to change tty inodes but that's what
/dev/pts is for.

If you do need read-write access to /dev but not /, put it on a
separate filesystem.  Leave just a skeletal /dev in your root
filesystem, enough to bootstrap.

Peter

Re: [lvm-devel] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com

[Christoph Hellwig]

On Wed, Feb 21, 2001 at 10:12:25PM -0600, Peter Samuelson wrote:
> 
> [Christoph Hellwig]
> > It would be really good to have something devfs-like just for LVM in
> > setups that don't use LVM, so we could avoid mounting root read/write
>                         ^^^devfs?

Yes...

> > for device-creation.
> 
> For most people, read/write access to /dev is rarely needed -- how
> often do you create new VGs or LVs?  How often do you run MAKEDEV or
> vgscan?

On every bootup, _before_ doing mount -a

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: [lvm-devel] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com

[Peter Samuelson]

  [Peter Samuelson]
> > How often do you run MAKEDEV or vgscan?

[Christoph Hellwig]
> On every bootup, _before_ doing mount -a

A mere 'vgchange -ay' works fine for *my* boot processes.  Is there a
particular reason to do 'vgscan' every time?  (I'm not arguing -- just
wondering.)

Peter

Re: [lvm-devel] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com

[Christoph Hellwig]

On Thu, Feb 22, 2001 at 04:52:51AM -0600, Peter Samuelson wrote:
> 
>   [Peter Samuelson]
> > > How often do you run MAKEDEV or vgscan?
> 
> [Christoph Hellwig]
> > On every bootup, _before_ doing mount -a
> 
> A mere 'vgchange -ay' works fine for *my* boot processes.  Is there a
> particular reason to do 'vgscan' every time?  (I'm not arguing -- just
> wondering.)

It is that what is suggested by the LVM crew.  I have also tried to use
it without vgscan - it work then and whenn, but not 100% percent reliable.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.
Whip me.  Beat me.  Make me maintain AIX.

Re: [linux-lvm] snapshot of Reiserfs

[Chris Mason]

On Wednesday, February 21, 2001 04:23:51 PM -0700 Andreas Dilger
<adilger@turbolinux.com> wrote:
> 
> Some overhead in calling sync_supers() and sync_supers_lockfs() because
> they do both do the same list traversal.  Granted, on most systems the
> total number of superblocks is small...  Last time I had a look at this,
> I suggested that the sync_supers_lockfs() call be changed, namely that
> it is illegal to call it with a zero "dev" parameter, otherwise you
> will lock all filesystems and that may be a bad thing.  This simplifies
> the code a bit.  If we also have it call write_super() if
> write_super_lockfs() is missing, it is better yet.
> 
It might be a stupid thing for the caller to do, but it should still work.
If I tried really hard, I might be able to think of some kind of clustering
deal where we wanted to checkpoint the current system and move it onto
another machine.  It would be a stretch though ;-)

>> It is amost exactly a cut n' paste of fsync_dev, with an extra call to
>> sync_supers_lockfs.  It should do what fsync_dev does, even when there
>> are no sync_super_lockfs methods are provided.  The only reason I didn't
>> just call fsync_dev from fsync_dev_lockfs is because I wanted the
>> sync_buffers call to happen after the lockfs call ;-)
> 
> And the reason for this is?  The first call to sync_buffers doesn't wait
> on completion (unlike the second sync_buffers call), so there is no
> guarantee that they are all written out.

The reason was to avoid a second call to sync_buffers that does wait on
completion....

You make some very good points.  The goal behind the existing call was to
do this:

1) flush as much as you can (inodes, supers, quotas, trigger buffer flushes)
2) ask the FS to lock itself.
3) make sure all dirty buffers are on disk

#2 might involve another set of flushes for anything that was modified
between #1 and the lock.  The FS is resonsible for this, since it might
have odd/complicated ways to figure out what is dirty (inodes under
reiserfs).

#3 is not allowed to deadlock against the FS lock, and it must go after the
lock to prevent new buffers from being dirtied after the sync.

Yes, this means scanning the list of supers twice, but I think it provides
a good mix of responsibilities between fsync_dev_lockfs call and the FS.
Any ideas on cleaning this up further are more than welcome.

-chris

[linux-lvm] Snapshot of ReiserFS

[Dietmar Stein]

Hi

I am new to the list, but I went through the archives and find some ideas
but not an approbiate answer ... I want to make a snapshot of a mounted
logical volume, which is formated with ReiserFS v3.6.

My configuration:
Compaq DL580 with SmartArray 5300 controller with Storage Enclosure 4312R
attached, 12 disks + 2 disks for system
SuSE Enterprise Server 8 (United Linux 1.0) with kernel 2.4.19-4GB, lvm
1.0.7

I have created six volume groups, consisting of two physical disks each;
each volume group (36 GB large) contains two logical volumes, each 10 GB.
The groups and volumes are labeled as

volgrp01, lv01vg01, lv02vg01 (volume group 01, logical volume 01 on volume
group 01 ...)
volgrp02, lv01vg02, lv02vg02
volgrp03, lv01vg03, lv02vg03

I have mounted lv01vg01 to /data_1 and I have created an empty file with dd
if=/dev/zero of=/data_1/testfile.raw bs=1M count=4000, then I followed
documentation and did a lvcreate -L 11000M -s -n snaplv01vg01
/dev/volgrp01/lv01vg01.

All I can see is harddisk activity, but the command prompt did not return
(I have been waiting for 2 hours), so I turned on verbose mode and last
message is "locking lvm" (something like that) and then I have been waiting
again.

What's the problem, mistake?

Thanks, Dietmar