From: Jan Kara <jack@suse.cz>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [Lsf-pc] [LSF/MM ATTEND] [TOPIC] fs/block interface discussions
Date: Wed, 10 Dec 2014 13:48:33 +0100 [thread overview]
Message-ID: <20141210124833.GG25671@quack.suse.cz> (raw)
In-Reply-To: <5488335C.9090605@redhat.com>
Hi,
On Wed 10-12-14 11:49:48, Steven Whitehouse wrote:
> I'm interested generally in topics related to integration between
> components, one example being snapshots. We have snapshots at
> various different layers (can be done at array level or dm/lvm level
> and also we have filesystem support in the form of fs freezing).
Well, usually snapshots at LVM layer are using fs freezing to get a
consistent image of a filesystem. So these two are integrated AFAICS.
> There are a few thoughts that spring to mind - one being how this
> should integrate with applications - in order to make it easier to
> use, and another being whether we could introduce snapshots which do
> not require freezing the fs (as per btrfs) for other filesystems too
> - possibly by passing down a special kind of flush from the
> filesystem layer.
So btrfs is special in its COW nature. For filesystems which do updates
in place you can do COW in the block layer (after all that's what
dm snapshotting does) but you still have to get fs into consistent state
(that's fsfreeze), then take snapshot of the device (by setting up proper
COW structures), and only then you can allow further modifications of the
filesystem by unfreezing it. I don't see a way around that...
> A more general topic is proposed changes to the fs/block interface,
> of which the above may possibly be one example. There are a number
> of proposals for new classes of block device, and new features which
> will potentially require a different (or extended) interface at the
> fs/block layer. These have largely been discussed to date as
> individual features, and I wonder whether it might be useful to try
> and bring together the various proposals to see if there is
> commonality between at least some of them at the fs/block interface
> level. I know that there have been discussions going on relating to
> the individual proposals, so the idea I had was to try and look at
> them from a slightly different angle by bringing as many of them as
> possible together and concentrating on how they would be used from a
> filesystem perspective,
Could you elaborate on which combination of features you'd like to
discuss?
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2014-12-10 12:48 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 ` Jan Kara [this message]
2014-12-10 14:13 ` [Cluster-devel] [Lsf-pc] " Steven Whitehouse
2014-12-10 18:46 ` Jan Kara
2014-12-11 0:52 ` Alasdair G Kergon
2014-12-12 11:46 ` Steven Whitehouse
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=20141210124833.GG25671@quack.suse.cz \
--to=jack@suse.cz \
/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).