[Lustre-discuss] Direct Snapshots of Lustre Filesystem & MDT size

Brian J. Murrell Brian.Murrell at Sun.COM
Fri Apr 17 08:17:59 PDT 2009


On Fri, 2009-04-17 at 15:37 +0200, Nick Jennings wrote:
> 
> Thanks for the reply Brian, I actually did try several searches
> regarding both questions, guess I just wasn't using the right keywords
> (was getting much more unrelated info).

"inode size" would probably find some relevant discussions on MDT size.

>  Snapshotting combined with offsite backup is what I'm going for here.

Well, snapshots are just a vehicle to getting the state of the target
"frozen".  You could achieve the same by simply taking the device
off-line, but that kind of down-time is unacceptable to some, hence the
option to use an LVM snapshot -- with it's penalties.

> Not a full copy of the filesystem on another set of (our) disks.

Well, no matter who/what it's on, you still need a "snapshot in time" to
make your copy from.  Whether that's to another disk (which you keep
locally or move offsite) or tape or whatever.

>  In the intro paragraph of section 15.3 (page 214 of the PDF) it says:
> To get around this problem [performance loss of snapshotting main Lustre
> filesystem], create a new, backup filesystem and periodically back up
> new/changed files. Take periodic snapshots of this backup filesystem to
> create a series of compact "full" backups.

Hrm.  Yeah.  Well, that really is your only answer to avoiding the
penalties of snapshotting your live filesystem.  There's no free lunch.

>  Maybe I'm misinterpreting that, but it seems to suggest coping any
> important data to a separate partition (w/LVM+snapshotting). If all my
> data is important, that's a full copy.

That's right.  Again, this is a balance between cost, performance and
redundancy.  Cheap, redundant, fast.  Pick two.  :-)

> This is what I'm going for. By lustre filesystem I meant more
> specifically, direct snapshotting of an OST, as opposed to a
> copy/snapshot on another partition.

You can most certainly snapshot an OST if it's an LVM target.  But there
are the usual COW performance caveats with that (for the life of the
snasphot(s) anyway).  Perhaps given your budget and data redundancy
requirements, the performance penalty (again, only while a snapshot is
present) is acceptable.  You will have to be the judge of that.

> Is there a downside to having just one large OST per OSS,

Only the 8TB device limitation, and perhaps backup considerations.  It
usually easier to back up smaller devices.  The larger your dataset
gets, the more difficulties you run into backing it up.

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-lustre.org/attachments/20090417/f1481574/attachment.pgp>


More information about the lustre-discuss mailing list