"Brad Voth" <brad@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
