From: Steven Whitehouse <swhiteho@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [LSF/MM ATTEND] [TOPIC] fs/block interface discussions
Date: Wed, 10 Dec 2014 11:49:48 +0000 [thread overview]
Message-ID: <5488335C.9090605@redhat.com> (raw)
Hi,
Here is my request to attend LSF/MM 2015. Since I last attended LSF/MM,
I now have rather wider interests in fs and storage than just GFS2,
although I'm still interested in that too. My interests now include many
other filesystems including NFS, CIFS, ext*, XFS, btrfs, overlayfs
including the common VFS and block interfaces, among other things.
Here are a few thoughts on topics which might be interesting to discuss....
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). 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.
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,
Steve.
next reply other threads:[~2014-12-10 11:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-10 11:49 Steven Whitehouse [this message]
2014-12-10 12:48 ` [Cluster-devel] [Lsf-pc] [LSF/MM ATTEND] [TOPIC] fs/block interface discussions 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
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=5488335C.9090605@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).