Hi,
On 11/12/14 00:52, Alasdair G Kergon wrote:
On Wed, Dec 10, 2014 at 07:46:51PM +0100, Jan Kara wrote:
But still you first need to stop all writes to the filesystem, then do a
sync, and then allow writing again - which is exactly what freeze does.
And with device-mapper, we were asked to support the taking of snapshots
of multiple volumes simultaneously (e.g. where the application data is
stored across more than one filesystem). Thin dm snapshots can handle
this (the original non-thin ones can't).
Alasdair
Thats good to know, and a useful feature. One of the issues I can see is
that because there are a number of different layers involved
(application/fs/storage) coordination of requirements between those is
not easy. To try to answer Jan's question earlier in the thread, no I
don't know any specific application developers, but I can certainly help
to propose some kind of solution, and then get some feedback. I think it
is probably going to be easier to start with a specific proposal, albeit
tentative, and then ask for feedback than to just say "how should we do
this?" which is a lot more open ended.
Going back to the other point above regarding freeze, is it not
necessarily a requirement to stop all writes in order to do a snapshot,
what is needed is in effect a barrier between operations which should be
represented in the snapshot and those which should not, because they
happen "after" the snapshot has been taken. Not that I'm particularly
attached to that proposal as it stands, but I hope it demonstrates the
kind of thing I had in mind for discussion. I hope also that it will be
possible to come up with a better solution during and/or following the
discussion.
The goal would really be to figure out which bits we already have,
which bits are missing, where the problems are, what can be done better,
and so forth, while we have at least two of the three layers represented
and in the same room. This is very much something for the long term
rather than a quick discussion followed by a few patches kind of thing,
I think,
Steve.
--
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
