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

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

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

[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

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