lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <OF3415C20F.793A0D3C-ON88257524.0067548F-88257524.0068BCEC@us.ibm.com>
Date:	Fri, 19 Dec 2008 11:03:56 -0800
From:	Bryan Henderson <hbryan@...ibm.com>
To:	"Brad Voth" <brad@...h.name>
Cc:	adilger@....com, "Andrew Morton" <akpm@...ux-foundation.org>,
	"Chris Mason" <chris.mason@...cle.com>,
	"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

"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"

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-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

Powered by Openwall GNU/*/Linux Powered by OpenVZ