Raid 5 (was: Mounting of Linux volumes)

Corey Edwards tensai at zmonkey.org
Fri Dec 2 09:26:26 MST 2005


On Thu, 2005-12-01 at 23:30 -0700, Andrew McNabb wrote:
> On Thu, Dec 01, 2005 at 11:03:03PM -0700, Nicholas Leippe wrote:
> > On Thursday 01 December 2005 10:55 pm, Andrew McNabb wrote:
> > > The DM system in Linux can do a snapshot (I believe LVM has an interface
> > > to it).  It's a very simple approach.
> > 
> > What kind of performance impact does it have?  Are there any constraints?
> > 
> 
> As far as I understand, the performance impact is negligible.  However,
> it is a pretty new feature, and from what I can tell on the web, each
> individual filesystem needs to support it by being able to flush just
> before the snapshot is taken.  It looks like xfs is the best-tested with
> it.

LVM has supported snapshots for quite a while (device mapper is just a
new way to do it) and I love them. Reiserfs also supports snapshots and
there are no special commands required like with xfs (xfs_freeze).

LVM 1 snapshots were strictly read-only, but LVM 2 can do read-write.
It's a copy-on-write strategy. Whenever a block is changed it is first
copied to the snapshot, then marked in the exception table. When you
create the snapshot volume you allocate a certain amount of space for
those exceptions. Obviously a more volatile volume will need more space
for a snapshot. If the snapshot fills it because unusable and the
original carries on like normal.

I've never done any scientific analysis to see how much impact that has,
but I've never noticed it either.

> All of this is just what I could glean from mailing list comments, so
> take it with a grain of salt.  I imagine that in the near future, LVM
> snapshots will become pretty practical.

The future is now.

Corey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://plug.org/pipermail/plug/attachments/20051202/2b0e7b49/attachment.bin 


More information about the PLUG mailing list