Hello Daire, You shared with the List:>We do backups from a few Lustre filesystems to a large single Lustre >filesystem using "e2scan" which can quickly scan the MDT for changed >files and dump out a list which can then be fed into something like >rsync and rm to synchronise filesystems. The Lustre e2fsprogs RPM includes >e2scan. I''m more than happy to send our bash script but it is pretty >hack-tastic!>DaireDo you run e2scan on a mounted system? I have been removing my Lustre disk from the clients and unmounting the MDT to do a getfattr and then a tar to back-up the metadata. (I have started to go to LVM but that transition is not yet complete.) Is e2scan run on the LVM like a snapshot? Please share more> Thank you, megan
Megan, ----- "Ms. Megan Larko" <dobsonunit at gmail.com> wrote:> Do you run e2scan on a mounted system?Yep. Works fine.> I have been removing my Lustre disk from the clients and unmounting the > MDT to do a getfattr and then a tar to back-up the metadata. (I have > started to go to LVM but that transition is not yet complete.) Is > e2scan run on the LVM like a snapshot? Please share more>If you are running a getfattr then I suppose you still need to unmount the MDT and mount it using "ldiskfs". Your approach is more for restoring a block device (like the MDT) whereas I just want to backup files and don''t care about what OSTs they were on and what their striping patterns were. Do you backup your OSTs in a similar way or are you just nervous about the MDT getting wiped/corrupted? Once you move to LVM then you can snapshot the MDT and mount that without unmounting the production MDT. You should probably destroy the snapshot afterwards as it affects performance somewhat. Regards, Daire
On Wed, 2009-03-04 at 17:03 +0000, Daire Byrne wrote:> > Once you move to LVM then you can snapshot the MDT and mount that without > unmounting the production MDT. You should probably destroy the snapshot > afterwards as it affects performance somewhat.And just to be absolutely clear for those who don''t realize, as the number of snapshots of a single device increases so does the performance penalty. There is another snapshot technology at http://zumastor.org/ that claims to efficiently store snapshots to as not to suffer the same problems. I have yet to find the time to evaluate it though. b. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.lustre.org/pipermail/lustre-discuss/attachments/20090304/56551688/attachment.bin
Brian, ----- "Brian J. Murrell" <Brian.Murrell at Sun.COM> wrote:> On Wed, 2009-03-04 at 17:03 +0000, Daire Byrne wrote: > > > > Once you move to LVM then you can snapshot the MDT and mount that without > > unmounting the production MDT. You should probably destroy the snapshot > > afterwards as it affects performance somewhat. > > And just to be absolutely clear for those who don''t realize, as the > number of snapshots of a single device increases so does the > performance penalty. > > There is another snapshot technology at http://zumastor.org/ that > claims to efficiently store snapshots to as not to suffer the same problems. > I have yet to find the time to evaluate it though.I looked at zumastor. Although it didn''t get any slower with extra snapshots it took quite a hit (~ x6 drop in writes) with just a single snapshot. It was also a bit buggy and I didn''t particularly like the userspace<->kernel interface. Far more promising is the port of zumastor exceptions to the kernel and the work being done to add a generic shared exception store interface to device-mapper (and ultimately LVM): https://www.redhat.com/archives/dm-devel/2009-February/msg00014.html It is a Redhat effort so it might actually be useful one day. Daire
On Wed, 2009-03-04 at 17:42 +0000, Daire Byrne wrote:> Brian,Hi Daire,> I looked at zumastor. Although it didn''t get any slower with extra snapshots > it took quite a hit (~ x6 drop in writes) with just a single snapshot.Ouch!> Far more promising is the port of zumastor exceptions to the kernel and the work > being done to add a generic shared exception store interface to device-mapper > (and ultimately LVM): > > https://www.redhat.com/archives/dm-devel/2009-February/msg00014.htmlCool. Thanx for the pointer!> It is a Redhat effort so it might actually be useful one day.Heh. I guess with this economy, only time will tell. b. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.lustre.org/pipermail/lustre-discuss/attachments/20090304/17c279ad/attachment-0001.bin