[linux-lvm] with 2.4.1, should I use beta2 or beta3 lvm-tools?

[linux-lvm] with 2.4.1, should I use beta2 or beta3 lvm-tools?

[Håkan Jettingstad]

Hello!

Just a quick question, kernel 2.4.1 contains lvm 0.9.1beta2, so I'm
wondering do I have to use the beta2 lvm-tools or can I use the beta3
lvm-tools with that kernel, or do I have to wait for a beta3 patch for the
2.4.1 kernel?

Thanks in advance,

Håkan Jettingstad

Re: [linux-lvm] with 2.4.1, should I use beta2 or beta3 lvm-tools?

[Joe Thornber]

On Fri, Feb 02, 2001 at 11:15:25AM +0100, H�kan Jettingstad wrote:
> Hello!
> 
> Just a quick question, kernel 2.4.1 contains lvm 0.9.1beta2, so I'm
> wondering do I have to use the beta2 lvm-tools or can I use the beta3
> lvm-tools with that kernel, or do I have to wait for a beta3 patch for the
> 2.4.1 kernel?

Please use the latest code if you can.  The LVM tar balls will build a
patch for your kernel.  If you don't want to patch your kernel
yourself then use the latest tools with 2.4.1, but you should probably
refrain from using snapshots.  We hope to make another release at the
beginning of next week (probably beta4).

- Joe

Re: [linux-lvm] with 2.4.1, should I use beta2 or beta3 lvm-tools?

[Rik van Riel]

On Fri, 2 Feb 2001, Joe Thornber wrote:
> On Fri, Feb 02, 2001 at 11:15:25AM +0100, H�kan Jettingstad wrote:
> > 
> > Just a quick question, kernel 2.4.1 contains lvm 0.9.1beta2, so I'm
> > wondering do I have to use the beta2 lvm-tools or can I use the beta3
> > lvm-tools with that kernel, or do I have to wait for a beta3 patch for the
> > 2.4.1 kernel?
> 
> Please use the latest code if you can.  The LVM tar balls will
> build a patch for your kernel.  If you don't want to patch your
> kernel yourself then use the latest tools with 2.4.1, but you
> should probably refrain from using snapshots.  We hope to make
> another release at the beginning of next week (probably beta4).

Who cares ?

As far as the majority of the LVM users are concerned,
new releases are shipped by Alan and Linus.

I guess having a separate LVM tree for development is
good, but it might be better to just do maintenance on
the tree which is actually being used - ie. Linus'.

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: [linux-lvm] with 2.4.1, should I use beta2 or beta3 lvm-tools?

[Joe Thornber]

On Fri, Feb 02, 2001 at 11:53:13AM -0200, Rik van Riel wrote:
> > Please use the latest code if you can.  The LVM tar balls will
> > build a patch for your kernel.  If you don't want to patch your
> > kernel yourself then use the latest tools with 2.4.1, but you
> > should probably refrain from using snapshots.  We hope to make
> > another release at the beginning of next week (probably beta4).
> 
> Who cares ?

Users who do not wish to check code out of CVS.  People who are
willing to put in time testing code for us.

> I guess having a separate LVM tree for development is
> good, but it might be better to just do maintenance on
> the tree which is actually being used - ie. Linus'.

?

2.4.1 has beta2 in it, we have been maintaining this to produce beta3
and shortly beta4.  Alan and Linus have been sent these updates but as
I'm sure you know it takes time for patches to get into the kernel.

Was there a point to your post or were you just trying to irritate us?

- Joe

Re: [linux-lvm] with 2.4.1, should I use beta2 or beta3 lvm-tools?

[Rik van Riel]

On Fri, 2 Feb 2001, Joe Thornber wrote:

> 2.4.1 has beta2 in it, we have been maintaining this to produce
> beta3 and shortly beta4.  Alan and Linus have been sent these
> updates

Interesting, the only reference to LVM in Linus' changelog
is the following:

- Andrea Arkangeli: LVM update

And I seem to remember only a more limited patch by Andrea
which solved one or two problems. Did Andrea send your release
to Linus or did he send his own set of bugfixes ?

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: [linux-lvm] with 2.4.1, should I use beta2 or beta3 lvm-tools?

[Joe Thornber]

On Fri, Feb 02, 2001 at 02:35:46PM -0200, Rik van Riel wrote:
> On Fri, 2 Feb 2001, Joe Thornber wrote:
> 
> > 2.4.1 has beta2 in it, we have been maintaining this to produce
> > beta3 and shortly beta4.  Alan and Linus have been sent these
> > updates
> 
> Interesting, the only reference to LVM in Linus' changelog
> is the following:
> 
> - Andrea Arkangeli: LVM update
> 
> And I seem to remember only a more limited patch by Andrea
> which solved one or two problems. Did Andrea send your release
> to Linus or did he send his own set of bugfixes ?

As well as providing valuable LVM patches Andrea has been forwarding
our releases to Linus, he seems to have a 'fast path' to the kernel.

- Joe

Re: [linux-lvm] with 2.4.1, should I use beta2 or beta3 lvm-tools?

[Rik van Riel]

On Fri, 2 Feb 2001, Joe Thornber wrote:
> On Fri, Feb 02, 2001 at 02:35:46PM -0200, Rik van Riel wrote:
> > On Fri, 2 Feb 2001, Joe Thornber wrote:
> > 
> > > 2.4.1 has beta2 in it, we have been maintaining this to produce
> > > beta3 and shortly beta4.  Alan and Linus have been sent these
> > > updates
> > 
> > Interesting, the only reference to LVM in Linus' changelog
> > is the following:
> > 
> > - Andrea Arkangeli: LVM update
> 
> As well as providing valuable LVM patches Andrea has been
> forwarding our releases to Linus, he seems to have a 'fast path'
> to the kernel.

OK, cool. For the last few weeks I've been fooled into
thinking that the LVM folks would never send their stuff
to Linus and we'd all be relying on other people to get
the necessary bugfixes in the kernel.

I'm happy to be proven wrong...

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: [linux-lvm] with 2.4.1, should I use beta2 or beta3 lvm-tools?

[Gregory McLean]

On Fri, 2 Feb 2001, Joe Thornber wrote:

> On Fri, Feb 02, 2001 at 11:15:25AM +0100, H�kan Jettingstad wrote:
> > Hello!
> >
> > Just a quick question, kernel 2.4.1 contains lvm 0.9.1beta2, so I'm
> > wondering do I have to use the beta2 lvm-tools or can I use the beta3
> > lvm-tools with that kernel, or do I have to wait for a beta3 patch for the
> > 2.4.1 kernel?
>
> Please use the latest code if you can.  The LVM tar balls will build a
> patch for your kernel.  If you don't want to patch your kernel

That won't apply cleanly.. I got lots of conflicts that I didn't have the
time to sort properly.

Re: [linux-lvm] with 2.4.1, should I use beta2 or beta3 lvm-tools?

[Joe Thornber]

On Fri, Feb 02, 2001 at 11:25:33AM -0500, Gregory McLean wrote:
> On Fri, 2 Feb 2001, Joe Thornber wrote:
> 
> > On Fri, Feb 02, 2001 at 11:15:25AM +0100, H�kan Jettingstad wrote:
> > > Hello!
> > >
> > > Just a quick question, kernel 2.4.1 contains lvm 0.9.1beta2, so I'm
> > > wondering do I have to use the beta2 lvm-tools or can I use the beta3
> > > lvm-tools with that kernel, or do I have to wait for a beta3 patch for the
> > > 2.4.1 kernel?
> >
> > Please use the latest code if you can.  The LVM tar balls will build a
> > patch for your kernel.  If you don't want to patch your kernel
> 
> That won't apply cleanly.. I got lots of conflicts that I didn't have the
> time to sort properly.

2.4.1 hadn't been released when we made the beta3 tarball.  If you
want to make a beta3 patch for the kernel create an empty file call
PATCHES/fragments-2.4.1 (2.4.1 needs no extra fragments) then run
PATCHES/make.  That should remove all the conflicts.

Or checkout the LVM_0-9-patches branch of CVS.

- Joe

[linux-lvm] Snapshots with 2.4.1?

[Tracy R Reed]

On Fri, Feb 02, 2001 at 04:56:42PM +0000, Joe Thornber wrote:
> 2.4.1 hadn't been released when we made the beta3 tarball.  If you
> want to make a beta3 patch for the kernel create an empty file call
> PATCHES/fragments-2.4.1 (2.4.1 needs no extra fragments) then run
> PATCHES/make.  That should remove all the conflicts.

I need to get snapshots working with 2.4.1. I've tried using just the
straight LVM that comes with the kernel and I have tried applying the
patches as described above. I either case, when I uncomment:

#define LVM_VFS_ENHANCEMENT 

in drivers/md/lvm.c to enable the hooks for snapshots the compile fails:

drivers/md/mddev.o: In function `lvm_do_lv_create':
drivers/md/mddev.o(.text+0x11bdb): undefined reference to `fsync_dev_lockfs'
drivers/md/mddev.o(.text+0x11c90): undefined reference to `unlockfs'

Can someone point out what else I am missing?

--
Tracy Reed      http://www.ultraviolet.org
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer

Re: [linux-lvm] Snapshots with 2.4.1?

[Chris Mason]

On Wednesday, February 07, 2001 02:25:10 PM -0800 Tracy R Reed <treed@ultraviolet.org> wrote:

> On Fri, Feb 02, 2001 at 04:56:42PM +0000, Joe Thornber wrote:
>> 2.4.1 hadn't been released when we made the beta3 tarball.  If you
>> want to make a beta3 patch for the kernel create an empty file call
>> PATCHES/fragments-2.4.1 (2.4.1 needs no extra fragments) then run
>> PATCHES/make.  That should remove all the conflicts.
> 
> I need to get snapshots working with 2.4.1. I've tried using just the
> straight LVM that comes with the kernel and I have tried applying the
> patches as described above. I either case, when I uncomment:
> 
> #define LVM_VFS_ENHANCEMENT 
> 
> in drivers/md/lvm.c to enable the hooks for snapshots the compile fails:
> 
> drivers/md/mddev.o: In function `lvm_do_lv_create':
> drivers/md/mddev.o(.text+0x11bdb): undefined reference to `fsync_dev_lockfs'
> drivers/md/mddev.o(.text+0x11c90): undefined reference to `unlockfs'
> 
> Can someone point out what else I am missing?
> 

This patch should do it, the reiserfs in 2.4.1 has code to take advantage of it.

diff -urN diff/linux/fs/buffer.c linux/fs/buffer.c
--- diff/linux/fs/buffer.c	Tue Oct  3 12:31:22 2000
+++ linux/fs/buffer.c	Tue Oct  3 12:16:16 2000
@@ -312,6 +312,28 @@
 	return sync_buffers(dev, 1);
 }
 
+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) ;
+}
+
 asmlinkage long sys_sync(void)
 {
 	fsync_dev(0);
diff -urN diff/linux/fs/super.c linux/fs/super.c
--- diff/linux/fs/super.c	Tue Oct  3 12:31:23 2000
+++ linux/fs/super.c	Fri Sep 29 10:01:09 2000
@@ -628,6 +628,46 @@
 	}
 }
 
+/*
+ * Note: don't check the dirty flag before waiting, we want the lock
+ * to happen every time this is called.
+ */
+void sync_supers_lockfs(kdev_t dev)
+{
+	struct super_block * sb;
+
+	for (sb = sb_entry(super_blocks.next);
+	     sb != sb_entry(&super_blocks); 
+	     sb = sb_entry(sb->s_list.next)) {
+		if (!sb->s_dev)
+			continue;
+		if (dev && sb->s_dev != dev)
+			continue;
+		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);
+		unlock_super(sb);
+	}
+}
+
+void unlockfs(kdev_t dev)
+{
+	struct super_block * sb;
+
+	for (sb = sb_entry(super_blocks.next);
+	     sb != sb_entry(&super_blocks); 
+	     sb = sb_entry(sb->s_list.next)) {
+		if (!sb->s_dev)
+			continue;
+		if (dev && sb->s_dev != dev)
+			continue;
+		if (sb->s_dev && (!dev || dev == sb->s_dev))
+			if (sb->s_op && sb->s_op->unlockfs)
+				sb->s_op->unlockfs(sb);
+	}
+}
+
 /**
  *	get_super	-	get the superblock of a device
  *	@dev: device to get the superblock for