Reiserfs, 2.4.7, snapshots w/ 0.9
I'm using LVM on a couple of our production systems, and I'm very happy with it. It's been working very well for us. However, we have a very large database and backing it up has become problematic.
So, naturally, I began looking into using LVM's snapshot feature. The filesystem the database rests on is a reiserfs partition. Creating the snapshot volume (acc to the directions in the howto) works fine, but when I try to actually mount it I get:
$ sudo mount -t reiserfs -oro /dev/main/db_backup /mnt/dbbackup
mount: wrong fs type, bad option, bad superblock on /dev/main/db_backup,
or too many mounted file systemschecking dmesg reveals:
reiserfs: checking transaction log (device 3a:04) ...
clm-2076: device is readonly, unable to replay log Replay Failure, unable to mountreiserfs_read_super: unable to initialize journal space
Ok, so I did some searching and found some people back in the first part of this year had a similar problems but none of the solutions really applied to me fwict. They all appeared to be using a previous version of the kernel, or of the lvm code. I looked through the changelog and did see a few notations of fixes since 0.9 related to the snapshot code. But, I'm kind of wary about putting a beta on my production systems with something this critical, w/out knowing for sure that it will fix the problem.
So, is the problem in lvm? reiserfs? Or is it just me? Is there any other information I can give that might be helpfull in figuring out the problem? Just let me know.
TIA
Quoted 32 lines · you
I'm using LVM on a couple of our production systems, and I'm very happy with it. It's been working very well for us. However, we have a very large database and backing it up has become problematic.
So, naturally, I began looking into using LVM's snapshot feature. The filesystem the database rests on is a reiserfs partition. Creating the snapshot volume (acc to the directions in the howto) works fine, but when I try to actually mount it I get:
$ sudo mount -t reiserfs -oro /dev/main/db_backup /mnt/dbbackup mount: wrong fs type, bad option, bad superblock on /dev/main/db_backup, or too many mounted file systemschecking dmesg reveals:
reiserfs: checking transaction log (device 3a:04) ...
clm-2076: device is readonly, unable to replay log Replay Failure, unable to mountreiserfs_read_super: unable to initialize journal spaceOk, so I did some searching and found some people back in the first part of this year had a similar problems but none of the solutions really applied to me fwict. They all appeared to be using a previous version of the kernel, or of the lvm code. I looked through the changelog and did see a few notations of fixes since 0.9 related to the snapshot code. But, I'm kind of wary about putting a beta on my production systems with something this critical, w/out knowing for sure that it will fix the problem.
So, is the problem in lvm? reiserfs? Or is it just me? Is there any other information I can give that might be helpfull in figuring out the problem? Just let me know.
Quoted 6 lines
TIA
_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
Quote from Teigland and Mauelshagens's Volume Manager whitepaper:
"If a snapshot is simply taken of a file system volume, the resulting copy of the file system will look as if the system has crashed. When the snapped file system is then mounted read only it would appear to need an fsck, in the case of a non journalled file system, or journal recovery in the case of a journalled file system. These operations (fsck or journal replay) require writing to the snapshot ligical volume, which is not allowed."
There's more, get the whole thing from sistina.com/lvm. Look for vmil_freenix.pdf.
Question to Heinz - what is the status of getting file system snapshot hooks into the kernel??
iain
Quoted 49 lines · Iain Campbell
Quoted 32 lines · you
I'm using LVM on a couple of our production systems, and I'm very happy with it. It's been working very well for us. However, we have a very large database and backing it up has become problematic.
So, naturally, I began looking into using LVM's snapshot feature. The filesystem the database rests on is a reiserfs partition. Creating the snapshot volume (acc to the directions in the howto) works fine, but when I try to actually mount it I get:
$ sudo mount -t reiserfs -oro /dev/main/db_backup /mnt/dbbackup mount: wrong fs type, bad option, bad superblock on /dev/main/db_backup, or too many mounted file systemschecking dmesg reveals:
reiserfs: checking transaction log (device 3a:04) ...
clm-2076: device is readonly, unable to replay log Replay Failure, unable to mountreiserfs_read_super: unable to initialize journal spaceOk, so I did some searching and found some people back in the first part of this year had a similar problems but none of the solutions really applied to me fwict. They all appeared to be using a previous version of the kernel, or of the lvm code. I looked through the changelog and did see a few notations of fixes since 0.9 related to the snapshot code. But, I'm kind of wary about putting a beta on my production systems with something this critical, w/out knowing for sure that it will fix the problem.
So, is the problem in lvm? reiserfs? Or is it just me? Is there any other information I can give that might be helpfull in figuring out the problem? Just let me know.
Quoted 6 lines
TIA
_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.htmlQuote from Teigland and Mauelshagens's Volume Manager whitepaper:
"If a snapshot is simply taken of a file system volume, the resulting copy of the file system will look as if the system has crashed. When the snapped file system is then mounted read only it would appear to need an fsck, in the case of a non journalled file system, or journal recovery in the case of a journalled file system. These operations (fsck or journal replay) require writing to the snapshot ligical volume, which is not allowed."
Quoted 5 lines
There's more, get the whole thing from sistina.com/lvm. Look for vmil_freenix.pdf.
Question to Heinz - what is the status of getting file system snapshot hooks into the kernel??
Have forwarded that to Chris Mason who created the VFS interface.
Quoted 9 lines
iain
_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
Signature · 15 lines
Regards,
Heinz -- The LVM Guy --
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf
Germany
[email protected] +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-Re: [linux-lvm] Some ideas regarding snapshots (was: Reiserfs, 2.4.7, snapshots w/ 0.9)
In reply to Iain CampbellIain Campbell ([email protected]) wrote 64 lines:
Quoted 4 lines
Quote from Teigland and Mauelshagens's Volume Manager whitepaper:
journalled file system. These operations (fsck or journal replay) require writing to the snapshot ligical volume, which is not allowed."
On a related subject: would it be possible to have a writable snapshot (probably a 'reverse' snapshot)?
I remember a few situations where I would have done a lot for a feature like that; e.g. building a system that's 'guaranteed' the same after restarting/rebooting it.
The idea is along the lines of:
- you have the system in a known good, fscked state on the HD.
- you snapshot that (possibly huge) system
- you mount the snapshots r/w
- the original will probably stay unmounted or r/o (but not neccessarily, I am thinking of robust, networked stand-alone devices which could be upgraded in the background while running; a simple restart will have the upgrade applied.)
- The system can scribble onto the snapshots until they are full.
- To reset the complete system to the known good state, umount, unsnapshot, start over. Or even -- horror -- reboot.
This should be *much* faster than a reintarnation or the use of dd, not to mention easier, simpler, more elegant and using less space.
And on another related idea: can we have the option of making snapshots non-persistant again? Or is that lots of work? There sometimes are cases where snapshots lose all value over a reboot, so they could/should automagically disappear.
-Wolfgang
Re: [linux-lvm] Some ideas regarding snapshots (was: Reiserfs, 2.4.7, snapshots w/ 0.9)
Quoted 8 lines · Wolfgang Weisselberg
Iain Campbell ([email protected]) wrote 64 lines:
Quoted 4 lines
Quote from Teigland and Mauelshagens's Volume Manager whitepaper:
journalled file system. These operations (fsck or journal replay) require writing to the snapshot ligical volume, which is not allowed."
On a related subject: would it be possible to have a writable snapshot (probably a 'reverse' snapshot)?
Writeable snapshot's are easy to implement, I believe someone has already made a patch for the current LVM series (search the list). I certainly intend putting it into the experimental LVM branch soon.
- Joe
Mark,
Chris Mason implemented an interface between the VFS and LVM, which is defined by 2 new functions VFS functions. They have to be supported in the filesystem itself in order to flush the journal and lock the filesystem for I/O, get back to LVM so that it can activate the prepared snapshot. LVM unlocks the filesystem after this.
You pay a (small) I/O penalty for the journal flush.
Because those functions are not in vanilla, you still need to patch the kernel with the linux-2.4.X-VFS-lock-patch contained in the LVM distribution :-(
That patch will enable the above feature after a kernel recompile/reboot.
Quoted 38 lines · Mark Bainter
I'm using LVM on a couple of our production systems, and I'm very happy with it. It's been working very well for us. However, we have a very large database and backing it up has become problematic.
So, naturally, I began looking into using LVM's snapshot feature. The filesystem the database rests on is a reiserfs partition. Creating the snapshot volume (acc to the directions in the howto) works fine, but when I try to actually mount it I get:
$ sudo mount -t reiserfs -oro /dev/main/db_backup /mnt/dbbackup mount: wrong fs type, bad option, bad superblock on /dev/main/db_backup, or too many mounted file systemschecking dmesg reveals:
reiserfs: checking transaction log (device 3a:04) ...
clm-2076: device is readonly, unable to replay log Replay Failure, unable to mountreiserfs_read_super: unable to initialize journal spaceOk, so I did some searching and found some people back in the first part of this year had a similar problems but none of the solutions really applied to me fwict. They all appeared to be using a previous version of the kernel, or of the lvm code. I looked through the changelog and did see a few notations of fixes since 0.9 related to the snapshot code. But, I'm kind of wary about putting a beta on my production systems with something this critical, w/out knowing for sure that it will fix the problem.
So, is the problem in lvm? reiserfs? Or is it just me? Is there any other information I can give that might be helpfull in figuring out the problem? Just let me know.
TIA
_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
Signature · 15 lines
Regards,
Heinz -- The LVM Guy --
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf
Germany
[email protected] +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-Quoted 10 lines · Heinz J . Mauelshagen
Mark,
Chris Mason implemented an interface between the VFS and LVM, which is defined by 2 new functions VFS functions. They have to be supported in the filesystem itself in order to flush the journal and lock the filesystem for I/O, get back to LVM so that it can activate the prepared snapshot. LVM unlocks the filesystem after this.
You pay a (small) I/O penalty for the journal flush.
Quoted 3 lines
Because those functions are not in vanilla, you still need to patch the kernel with the linux-2.4.X-VFS-lock-patch contained in the LVM distribution :-(
Does it mean that, to support XFS snapshots you need to apply the patch ?.
http://linuxtoday.com/news_story.php3?ltsn=2001-07-11-011-20-NW-SW
This announcement says XFS 1.0.1 has "LVM snapshotting capability added", but it says nothing about additional kernel patches required.
Could you clarify please ?.
--
Jos� Luis Domingo L�pez
Linux Registered User #189436 Debian GNU/Linux Potato (P166 64 MB RAM)
jdomingo EN internautas PUNTO org => � Spam ? Atente a las consecuencias
jdomingo AT internautas DOT org => Spam at your own risk