From: "Lukáš Czerner" <lczerner@redhat.com>
To: lsf-pc@lists.linux-foundation.org
Cc: linux-fsdevel@vger.kernel.org
Subject: [LSF/MM TOPIC] [ATTEND] fs 'umbrella' library, fs featuresinteroperability and extent locking
Date: Wed, 13 Feb 2013 16:06:00 +0100 (CET) [thread overview]
Message-ID: <alpine.LFD.2.00.1302131600520.24429@localhost> (raw)
Hello,
I'd like to discuss an idea to create an umbrella library for file system
user space utilities mainly fsck and mkfs. The reason for this is that the
current state where the application trying to create/manipulate the file
systems needs to use file system binaries itself and the parse output which
is not pretty nor viable in the long run. We rally need libraries for the
applications to use them and since fsck, mkfs and tools to retrieve various
specific information from the file systems have lots in common across the
different file system the 'umbrella' library could provide all the common
operation. I guess that the trick here would be to make it generic enough
to cover possibly any linux file system, however still make it interesting
and usable.
The other think I would like to talk about with the rest of the ext4 crew
and possibly other file system people is the amount of mount options/features
file systems support. There is the problem with interoperability between
various file system features which is not usually very well documented or
untested, not talking about the fact that some combination are never tested.
We should discuss common practices when adding new file system features/mount
options to avoid such problem in general and the possibility of removing
mount options without breaking user setups.
Last but not least there is the idea of extent locking which has already
been poked at several times by several people. I think that this is a perfect
time to discuss the generic file system independent design of extent/range
locking mechanism. Jan Kara already have a proposal for this topic
(Mapping range locking) and it seems that Zheng Liu is working on the same
thing for ext4.
Thanks!
-Lukas
reply other threads:[~2013-02-13 15:06 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=alpine.LFD.2.00.1302131600520.24429@localhost \
--to=lczerner@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
/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).