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



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