[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1229715015.6695.71.camel@think.oraclecorp.com>
Date: Fri, 19 Dec 2008 14:30:15 -0500
From: Chris Mason <chris.mason@...cle.com>
To: Bryan Henderson <hbryan@...ibm.com>
Cc: Brad Voth <brad@...h.name>, adilger@....com,
Andrew Morton <akpm@...ux-foundation.org>,
Christoph Hellwig <hch@...radead.org>,
Jeff Garzik <jeff@...zik.org>,
Kay Sievers <kay.sievers@...y.org>,
linux-btrfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, sfr@...b.auug.org.au
Subject: Re: Notes on support for multiple devices for a single filesystem
On Fri, 2008-12-19 at 11:03 -0800, Bryan Henderson wrote:
> "Brad Voth" <brad@...h.name> wrote on 12/18/2008 01:36:12 PM:
>
> > I can see the desire to have the snapshot at the filesystem level to
> > ensure that the filesystem knows it is consistent. However, this
> > can be a duplication of effort because of the need to have snapshots
> > at the block device level for non-fs devices. Such as raw logical
> > devices for say a database. I would think that a viable consistent
> > solution would be to have the block device snapshot mechanism have a
> > hook into the filesystem api to say, "I'm preparing to take a
> > snapshot, please quiesce and return" <take block snapshot> "You may
> > now resume, Mr. Filesystem"
This is what lvm does now with the write_super_lockfs calls. They work
well for a specific purpose.
At the end of the day snapshots mean different things to different
people and different workloads. In lots of ways the lvm snapshots work
very well.
But, doing snapshots at the FS level gives you better performance and
more control.
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists