"Brad Voth" <[email protected]> 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"
But that's a layering violation. First of all, a block device doesn't
know what a filesystem is, so you'd have to generalize it to making these
requests to whatever has the block device in some sense open. I don't see
that this sequence gains you anything over the sequence I described where
the user makes the request of the filesystem driver and the filesystem
driver, while it has the filesystem quiesced, issues an order to the block
device to make a snapshot.
>In this way there is a single interface for users to take snapshots
>of the block device level whether it is a raw logical volume, or a
>filesystem sitting on a logical volume.
I don't think it makes sense to have a common means of snapshotting any of
the various things that might reside on a block device; for some, I can't
even think of a meaningful concept of snapshotting the information on that
device. E.g. where it's one of 4 disks on which some filesystem resides.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Storage Systems
On Fri, 2008-12-19 at 11:03 -0800, Bryan Henderson wrote:
> "Brad Voth" <[email protected]> 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