mounting reiserfs snapshot fails

linux-lvm Ed Tomlinson 3 participants 10 messages Apr 13, 2001 – Apr 30, 2001

lore

Share & tools

lore

Ed Tomlinson

author

2001-04-13 17:29 UTC #0 lore raw

Hi,

Using debian sid, 2.4.3-ac5, lvm 0.91 beta7, with the vfs locking patch applied I get:

oscar# mount /dev/lv/snap /snap -t reiserfs -oro
mount: wrong fs type, bad option, bad superblock on /dev/lv/snap,
or too many mounted file systems

When trying to mount the snap shot. It was created with:
lvcreate -L 1G -s -n snap /dev/lv/root /dev/hdg1 without problems

Ideas?
Ed Tomlinson

Chris Mason

2001-04-13 20:36 UTC #1 lore raw

Quoted 8 lines · On Friday, April 13, 2001 01:29:58 PM -0400 Ed Tomlinson <[email protected]>…

Hi,
Using debian sid, 2.4.3-ac5, lvm 0.91 beta7, with the vfs locking patch applied I get:
oscar# mount /dev/lv/snap /snap -t reiserfs -oro
mount: wrong fs type, bad option, bad superblock on /dev/lv/snap,
or too many mounted file systems

BTW, you can drop the -o ro, LVM sets the snapshot device readonly, so VFS forces a readonly mount for you.

Quoted 4 lines

When trying to mount the snap shot. It was created with:
lvcreate -L 1G -s -n snap /dev/lv/root /dev/hdg1 without problems

I doubt it, but was /dev/lv/root a freshly created reiserfs disk?

What does dumpreiserfs tell you about /dev/lv/snap and /dev/lv/root tell you?

-chris

Ed Tomlinson

author

2001-04-13 22:42 UTC #2 lore raw

Quoted 15 lines · Chris Mason

On Friday, April 13, 2001 01:29:58 PM -0400 Ed Tomlinson <[email protected]>
Quoted 8 lines · wrote:
Hi,
Using debian sid, 2.4.3-ac5, lvm 0.91 beta7, with the vfs locking patch applied I get:
oscar# mount /dev/lv/snap /snap -t reiserfs -oro
mount: wrong fs type, bad option, bad superblock on /dev/lv/snap,
or too many mounted file systems
BTW, you can drop the -o ro, LVM sets the snapshot device readonly, so VFS forces a readonly mount for you.

Quoted 8 lines

Quoted 3 lines
When trying to mount the snap shot. It was created with:
lvcreate -L 1G -s -n snap /dev/lv/root /dev/hdg1 without problems
I doubt it, but was /dev/lv/root a freshly created reiserfs disk?
What does dumpreiserfs tell you about /dev/lv/snap and /dev/lv/root tell you?

oscar# lvcreate -L 1G -s -n snap /dev/lv/root /dev/hdg1
lvcreate -- WARNING: the snapshot will be automatically disabled once it gets full lvcreate -- INFO: using default snapshot chunk size of 64 KB for "/dev/lv/snap" lvcreate -- doing automatic backup of "lv"
lvcreate -- logical volume "/dev/lv/snap" successfully created

oscar# mount -t reiserfs /dev/lv/snap /snap
mount: block device /dev/lv/snap is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/lv/snap,
or too many mounted file systems

oscar# dumpreiserfs /dev/lv/snap
dumpe2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
dumpreiserfs: Bad magic number in super-block while trying to open /dev/lv/snap Couldn't find valid filesystem superblock.

oscar# dumpreiserfs /dev/lv/root
dumpe2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
dumpreiserfs: Bad magic number in super-block while trying to open /dev/lv/root Couldn't find valid filesystem superblock.oscar# debugreiserfs /dev/lv/snap

<-------------debugreiserfs, 2001-------------> reiserfsprogs 3.x.0j
reiserfs_open: neither new nor old reiserfs format found on /dev/lv/snap
print_block: buffer is NULL
oscar# debugreiserfs /dev/lv/root

<-------------debugreiserfs, 2001-------------> reiserfsprogs 3.x.0j
Super block of format 3.6 found on the 0x3 in block 16 Block count 3670016
Blocksize 4096
Free blocks 1241068
Busy blocks (skipped 16, bitmaps - 112, journal blocks - 8193 1 super blocks, 2420626 data blocks
Root block 40201
Journal block (first) 18
Journal dev 0
Journal orig size 8192
Filesystem state ERROR
Tree height 5
Hash function used to sort names: "r5"
Objectid map size 304, max 972
Version 2
oscar# = ?

Andreas Dilger

2001-04-14 00:23 UTC #3 lore raw

In reply to Ed Tomlinson

Quoted 10 lines · Ed Tomlinson

Using debian sid, 2.4.3-ac5, lvm 0.91 beta7, with the vfs locking patch applied I get:
oscar# mount /dev/lv/snap /snap -t reiserfs -oro
mount: wrong fs type, bad option, bad superblock on /dev/lv/snap,
or too many mounted file systems
When trying to mount the snap shot. It was created with:
lvcreate -L 1G -s -n snap /dev/lv/root /dev/hdg1 without problems

Are you sure that the VFS patch is applied, and that the LVM and reiserfs code was compiled with "enable VFS patch" (whatever it is called) enabled? That has been a source of problems in the past. The patch was applied, but you also need to enable it for both the reiserfs and LVM code.

Cheers, Andreas

Signature · 3 lines

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

Chris Mason

2001-04-14 00:53 UTC #4 lore raw

Quoted 12 lines · On Friday, April 13, 2001 06:23:28 PM -0600 Andreas Dilger…

Quoted 10 lines · Ed Tomlinson
Using debian sid, 2.4.3-ac5, lvm 0.91 beta7, with the vfs locking patch applied I get:
oscar# mount /dev/lv/snap /snap -t reiserfs -oro
mount: wrong fs type, bad option, bad superblock on /dev/lv/snap,
or too many mounted file systems
When trying to mount the snap shot. It was created with:
lvcreate -L 1G -s -n snap /dev/lv/root /dev/hdg1 without problems

Quoted 5 lines

Are you sure that the VFS patch is applied, and that the LVM and reiserfs code was compiled with "enable VFS patch" (whatever it is called) enabled? That has been a source of problems in the past. The patch was applied, but you also need to enable it for both the reiserfs and LVM code.

That would be a different error, reiserfs would complain that it found a filesystem, but was unable to mount it because it needed replay and the device was readonly. In this case, the snapshot is not a valid FS at all, even though the source looks fine.

I'll upgrade to the latest LVM and try to reproduce...

-chris

Ed Tomlinson

author

2001-04-18 01:38 UTC #5 lore raw

Quoted 1 line · Chris Mason

I'll upgrade to the latest LVM and try to reproduce...

This is still happening with ac7, which has the 2.4.4-pre3 fixes merged.

Chris Mason

2001-04-30 01:48 UTC #6 lore raw

In reply to Ed Tomlinson

Quoted 5 lines · On Friday, April 13, 2001 01:29:58 PM -0400 Ed Tomlinson <[email protected]>…

Hi,
Using debian sid, 2.4.3-ac5, lvm 0.91 beta7, with the vfs locking patch applied I get:

Quoted 7 lines

oscar# mount /dev/lv/snap /snap -t reiserfs -oro
mount: wrong fs type, bad option, bad superblock on /dev/lv/snap,
or too many mounted file systems
When trying to mount the snap shot. It was created with:
lvcreate -L 1G -s -n snap /dev/lv/root /dev/hdg1 without problems

I'm not sure what you're doing that I wasn't, but I've tried a bunch of times to reproduce this over the last few weeks. Tonight I finally did ;-)

The bug is that reiserfs needs to try harder to wait for the current transaction to end. A slight change in the semantics there didn't get carried into the reiserfs write_super_lockfs call (reiserfs_block_writes used to be enough on its own).

But, it only hits when LVM can create the snapshot faster than the next reiserfs writer can commit the transaction, which doesn't happen often for me.

Anyway, here's a patch (VFS locking patch for 2.4.4 will follow in a sec).

-chris

fs/reiserfs/super.c +1 -1

diff -Nru a/fs/reiserfs/super.c b/fs/reiserfs/super.c
@@ -80,7 +80,7 @@
     reiserfs_prepare_for_journal(s, SB_BUFFER_WITH_SB(s), 1);
     journal_mark_dirty(&th, s, SB_BUFFER_WITH_SB (s));
     reiserfs_block_writes(&th) ;
-    journal_end(&th, s, 1) ;
+    journal_end_sync(&th, s, 1) ;
   }
   s->s_dirt = dirty;
   unlock_kernel() ;

Ed Tomlinson

author

2001-04-30 04:23 UTC #7 lore raw

Quoted 24 lines · Chris Mason

On Friday, April 13, 2001 01:29:58 PM -0400 Ed Tomlinson <[email protected]>
Quoted 5 lines · wrote:
Hi,
Using debian sid, 2.4.3-ac5, lvm 0.91 beta7, with the vfs locking patch applied I get:
Quoted 7 lines
oscar# mount /dev/lv/snap /snap -t reiserfs -oro
mount: wrong fs type, bad option, bad superblock on /dev/lv/snap,
or too many mounted file systems
When trying to mount the snap shot. It was created with:
lvcreate -L 1G -s -n snap /dev/lv/root /dev/hdg1 without problems
I'm not sure what you're doing that I wasn't, but I've tried a bunch of times to reproduce this over the last few weeks. Tonight I finally did ;-)
The bug is that reiserfs needs to try harder to wait for the current transaction to end. A slight change in the semantics there didn't get carried into the reiserfs write_super_lockfs call (reiserfs_block_writes used to be enough on its own).

Quoted 5 lines

But, it only hits when LVM can create the snapshot faster than the next reiserfs writer can commit the transaction, which doesn't happen often for me.
Anyway, here's a patch (VFS locking patch for 2.4.4 will follow in a sec).

Chris,

This is not fixing the problem here. What else do you need to figure this one out? I did verify that I built from souce with both the fix VFS locking the the reiserfs fix applied. Symptoms remain the same, debugreiserfs is still finding a null block where it expects the sb.

Ed Tomlinson

author

2001-04-30 04:31 UTC #8 lore raw

Quoted 5 lines · Ed Tomlinson

Quoted 5 lines
The bug is that reiserfs needs to try harder to wait for the current transaction to end. A slight change in the semantics there didn't get carried into the reiserfs write_super_lockfs call (reiserfs_block_writes used to be enough on its own).

Quoted 8 lines

Quoted 3 lines
But, it only hits when LVM can create the snapshot faster than the next reiserfs writer can commit the transaction, which doesn't happen often for me.
This is not fixing the problem here. What else do you need to figure this one out? I did verify that I built from souce with both the fix VFS locking the the reiserfs fix applied. Symptoms remain the same, debugreiserfs is still finding a null block where it expects the sb.

Some more info.

If I use: lvcreate -L1G -s -n snap /dev/lv/root /dev/hdg1 the snapshoot is corrupt

if I use: lvcreate -L1G -s -n snap /dev/lv/root /dev/hde1 the snapshoot works

The difference being that /dev/lv/root is on /dev/hde1. hdg1 is basicly empty right now. Suspect there is still race in this process.

Chris Mason

2001-04-30 11:43 UTC #9 lore raw

In reply to Ed Tomlinson

Quoted 8 lines · On Monday, April 30, 2001 12:23:14 AM -0400 Ed Tomlinson <[email protected]>…

Chris,
This is not fixing the problem here. What else do you need to figure this one out? I did verify that I built from souce with both the fix VFS locking the the reiserfs fix applied. Symptoms remain the same, debugreiserfs is still finding a null block where it expects the sb.

Sigh. Could you please try 2.4.4aa2 + the two patches I sent? If that doesn't do it, I'll send along some debugging patches.

-chris