*** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com

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 <[email protected]>.

Quoted 2 lines · Heinz Mauelshagen

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.

Quoted 6 lines · Andreas Dilger

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

Quoted 1 line · Richard Gooch

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.

Quoted 1 line · Richard Gooch

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.

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.

[Christoph Hellwig]

Quoted 2 lines

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?

Quoted 1 line

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?

Quoted 1 line

How often do you run MAKEDEV or vgscan?

On every bootup, _before_ doing mount -a

[Peter Samuelson]

Quoted 1 line

Quoted 1 line

How often do you run MAKEDEV or vgscan?

[Christoph Hellwig]

Quoted 1 line

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

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

Quoted 3 lines · Heinz J. Mauelshagen

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

From: Patrick Caulfield <[email protected]>
Sender: [email protected]
To: [email protected]
Subject: Re: [linux-lvm] snapshot of Reiserfs
Date: Wed, 21 Feb 2001 08:59:59 +0000

Quoted 11 lines · On Tue, Feb 20, 2001 at 11:19:51PM -0500, [email protected] wrote:

Quoted 3 lines · Heinz J. Mauelshagen

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

Quoted 2 lines

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

Quoted 21 lines · Patrick Caulfield

From: Patrick Caulfield <[email protected]>
Sender: [email protected]
To: [email protected]
Subject: Re: [linux-lvm] snapshot of Reiserfs
Date: Wed, 21 Feb 2001 08:59:59 +0000

Quoted 13 lines · On Tue, Feb 20, 2001 at 11:19:51PM -0500, [email protected] wrote:

Quoted 3 lines · Heinz J. Mauelshagen

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

Quoted 3 lines

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.

Quoted 4 lines

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.

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

On Wednesday, February 21, 2001 02:11:20 PM +0000 Patrick Caulfield <[email protected]> wrote:

[ non-intuitive snapshot patches for reiserfs ]

Quoted 5 lines

Quoted 4 lines

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.

Quoted 4 lines

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?

Quoted 8 lines · On Tue, Feb 20, 2001 at 11:19:51PM -0500, [email protected] 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:

Quoted 11 lines · On Wednesday, February 21, 2001 09:44:39 AM -0700 Andreas Dilger…

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.

Quoted 2 lines

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.

Quoted 12 lines

Quoted 11 lines

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

Quoted 1 line

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.

Quoted 6 lines

Quoted 2 lines

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:

(quoted diff) +11 -0

+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);          

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

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.

Quoted 5 lines

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.