From: Matthew Wilcox <willy@infradead.org>
To: Jerome Glisse <jglisse@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>,
lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [LSF/MM TOPIC] Direct block mapping through fs for device
Date: Wed, 1 May 2019 18:52:14 -0700 [thread overview]
Message-ID: <20190502015214.GB8099@bombadil.infradead.org> (raw)
In-Reply-To: <20190429132643.GB3036@redhat.com>
On Mon, Apr 29, 2019 at 09:26:45AM -0400, Jerome Glisse wrote:
> This is a filesystem opt-in feature if a given filesystem do not want
> to implement it then just do not implement it and it will use page
> cache. It is not mandatory i am not forcing anyone. The first reasons
> for those are not filesystem but mmap of device file. But as LSF/MM
> is up i thought it would be a good time to maybe propose that for file-
> system too. If you do not want that for your filesystem then just NAK
> any patch that add that to filesystem you care about.
No. This is stupid, broken, and wrong. I know we already have
application-visible differences between filesystems, and every single one
of those is a bug. They may be hard bugs to fix, they may be bugs that we
feel like we can't fix, they may never be fixed. But they are all bugs.
Applications should be able to work on any Linux filesystem without
having to care what it is. Code has a tendency to far outlive its
authors expectations (and indeed sometimes its authors). If 'tar' had
an #ifdef XFS / #elsif EXT4 / #elsif BTRFS / ... #endif, that would be
awful.
We need the same semantics across all major filesystems. Anything else
is us making application developers lives harder than necessary, and
that's unacceptable.
next prev parent reply other threads:[~2019-05-02 1:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-26 1:38 [LSF/MM TOPIC] Direct block mapping through fs for device Jerome Glisse
2019-04-26 6:28 ` Dave Chinner
2019-04-26 12:45 ` Christoph Hellwig
2019-04-26 14:45 ` Darrick J. Wong
2019-04-26 14:47 ` Christoph Hellwig
2019-04-26 15:20 ` Jerome Glisse
2019-04-27 1:25 ` Dave Chinner
2019-04-29 13:26 ` Jerome Glisse
2019-05-01 23:47 ` Dave Chinner
2019-05-02 1:52 ` Matthew Wilcox [this message]
2019-04-26 20:28 ` Adam Manzanares
2019-04-26 20:28 ` Adam Manzanares
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=20190502015214.GB8099@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=david@fromorbit.com \
--cc=jglisse@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.