cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Steven Whitehouse <swhiteho@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [Lsf-pc] [LSF/MM ATTEND] [TOPIC] fs/block interface discussions
Date: Fri, 12 Dec 2014 11:46:34 +0000	[thread overview]
Message-ID: <548AD59A.8000007@redhat.com> (raw)
In-Reply-To: <20141211005222.GB26014@agk-dp.fab.redhat.com>

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.



  reply	other threads:[~2014-12-12 11:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-10 11:49 [Cluster-devel] [LSF/MM ATTEND] [TOPIC] fs/block interface discussions Steven Whitehouse
2014-12-10 12:48 ` [Cluster-devel] [Lsf-pc] " Jan Kara
2014-12-10 14:13   ` Steven Whitehouse
2014-12-10 18:46     ` Jan Kara
2014-12-11  0:52       ` Alasdair G Kergon
2014-12-12 11:46         ` Steven Whitehouse [this message]
2014-12-12 20:22           ` Jan Kara
2014-12-12 20:38             ` Alex Elsayed
2014-12-12 20:49               ` Alex Elsayed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=548AD59A.8000007@redhat.com \
    --to=swhiteho@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).