[Lustre-discuss] MDT estimated time for backup

[Andreas Dilger]

On Apr 29, 2009  10:36 -0400, Brian J. Murrell wrote:
> On Wed, 2009-04-29 at 10:17 -0400, Ms. Megan Larko wrote:
> > To execute the getfattr and
> > tar used to take me 3 to 8 hours.    My last attempt had tar -cf
> > running for over two days which was not acceptable to my users.
> 
> Has your dataset grown relative to those two different times?  Or has
> the process gotten less efficient somehow?

The problem with 1.6.7.1 is that the MDS now stores the size of
the file from the last time it is closed.  This was to be used
for some backup tools to generate a reasonable estimate of the
amount of data to be backed up, but has caused other issues.

> > Is getfattr and tar still preferred over rsync -aS
> 
> Well, I think the getfattr/tar method are time-tested.  I can't imagine
> why an rsync (or several of them, more on that below) that includes
> extended attributes (-X IIRC) in the sync wouldn't work either.  I don't
> think we've done any testing of the rsync method however.

The problem is that tar is trying to back up the "file data" from
the MDS inodes, but they are all sparse files with no data blocks.

> > or the getfattr and dump method?

I did a quick test with "dump" and it doesn't seem to try and read
all of the "sparse" file data, so you could give this a try.  The
minimum version of dump that claims extended attribute support is
0.4b40, though I haven't tested that.  In the absence of dump xattr
support you can still use the getfattr + dump + restore + setfattr
method described in the manual.  Always verify that "getfattr -d -m ".*"
on the restored MDS files returns a "trusted.lov" attribute.

> I'm not so sure you want to use dump.  dump effectively takes an image
> of the filesystem and restore that image exactly.  tar and rsync are
> more like taking the content out of the filesystem and recreating it.

That isn't quite true - the dump process does use device-level access
to create the backup, but the restore process is more like "tar" in
that it restores files by their pathname.


Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.