linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Whitehouse <swhiteho@redhat.com>
To: lsf-pc@lists.linux-foundation.org,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-block@vger.kernel.org
Cc: David Lehman <dlehman@redhat.com>, Jan Tulak <jtulak@redhat.com>,
	paul evans <pevans@redhat.com>,
	Justin Mitchell <jumitche@redhat.com>
Subject: [LSF/MM TOPIC] [LSF/MM ATTEND] FS Management Interfaces
Date: Tue, 10 Jan 2017 09:44:59 +0000	[thread overview]
Message-ID: <c13ef7f9-e687-5fcc-6fdb-5dd6f1122227@redhat.com> (raw)

Hi,

This is a request both to attend LSF/MM and also a topic proposal. The 
last couple of years I've proposed a topic of the block/fs interface. 
I'm happy to do that again, if there is consensus that this would be 
useful, however this time I thought that I'd propose something a bit 
different.

I had originally thought about calling the proposal "kernel/userland 
interface", however that seemed a bit vague and management interfaces 
seems like a better title since it is I hope a bit clearer of the kind 
of thing that I'm thinking about in this case.

There are a number of possible sub-topics and I hope that I might find a 
few more before LSF too. One is that of space management (we have 
statfs, but currently no notifications for thresholds crossed etc., so 
everything is polled. That is ok sometimes, but statfs can be expensive 
in the case of distributed filesystems, if 100% accurate. We could just 
have ENOSPC notifications for 100% full, or something more generic), 
another is state transitions (is the fs running normally, or has it gone 
read only/withdrawn/etc due to I/O errors?) and a further topic would be 
working towards a common interface for fs statistics (at the moment each 
fs defines their own interface). One potential implementation, at least 
for the first two sub-topics, would be to use something along the lines 
of the quota netlink interface, but since few ideas survive first 
contact with the community at large, I'm throwing this out for further 
discussion and feedback on whether this approach is considered the right 
way to go.

Assuming the topic is accepted, my intention would be to gather together 
some additional sub-topics relating to fs management to go along with 
those I mentioned above, and I'd be very interested to hear of any other 
issues that could be usefully added to the list for discussion.

My interest in other topics is fairly wide... I'm, as usual, interested 
in all filesystem related topics and a good number of block device and 
mm topics too. Anything relating to vfs, xfs, ext*, btrfs, gfs2, 
overlayfs, NFS/CIFS, and technologies such as copy-offload, DAX, 
reflink, RDMA, NVMe(F), etc.,

Steve.


             reply	other threads:[~2017-01-10  9:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-10  9:44 Steven Whitehouse [this message]
2017-01-10 10:14 ` [Lsf-pc] [LSF/MM TOPIC] [LSF/MM ATTEND] FS Management Interfaces Jan Kara
2017-01-11 12:07   ` Steven Whitehouse
2017-01-10 11:57 ` Lukas Czerner

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=c13ef7f9-e687-5fcc-6fdb-5dd6f1122227@redhat.com \
    --to=swhiteho@redhat.com \
    --cc=dlehman@redhat.com \
    --cc=jtulak@redhat.com \
    --cc=jumitche@redhat.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=pevans@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).