linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Matthew Wilcox <willy@infradead.org>,
	David Howells <dhowells@redhat.com>
Cc: ceph-devel@vger.kernel.org, idryomov@gmail.com,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] ceph: Uninline the data on a file opened for writing
Date: Fri, 17 Dec 2021 12:18:04 -0500	[thread overview]
Message-ID: <e2fcdecb9288dc112d0051e917da5bb48bf72388.camel@kernel.org> (raw)
In-Reply-To: <Yby4sKDALDXHAbdT@casper.infradead.org>

On Fri, 2021-12-17 at 16:20 +0000, Matthew Wilcox wrote:
> On Fri, Dec 17, 2021 at 03:29:45PM +0000, David Howells wrote:
> > If a ceph file is made up of inline data, uninline that in the ceph_open()
> > rather than in ceph_page_mkwrite(), ceph_write_iter(), ceph_fallocate() or
> > ceph_write_begin().
> 
> I don't think this is the right approach.  Just opening a file with
> O_RDWR shouldn't take it out of inline mode; an actual write (or fault)
> should be required to uninline it.
> 

This feature is being deprecated in ceph altogether, so more
aggressively uninlining of files is fine. The kernel cephfs client never
supported writes to it anyway so this feature was really only used by a
few brave souls.

We're hoping to have it formally removed by the time the Ceph Quincy
release ships (~April-May timeframe). Unfortunately, we need to keep
support for it around for a bit longer since some still-supported ceph
releases don't have this deprecated.

> > This makes it easier to convert to using the netfs library for VM write
> > hooks.
> 
> I don't understand.  You're talking about the fault path?  Surely
> the filesystem gets called with the vm_fault parameter only, then
> calls into the netfs code, passing vmf and the operations struct?
> And ceph could uninline there.
> 

Taking the uninlining out of the write codepaths is a _good_ thing, IMO.
If we were planning to keep this feature around, then I might disagree
with doing this, but it fits with the current plans for inline data just
fine for now.

-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2021-12-17 17:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-17 15:29 [PATCH v2 1/2] ceph: Uninline the data on a file opened for writing David Howells
2021-12-17 15:29 ` [PATCH v2 2/2] ceph: Remove some other inline-setting bits David Howells
2021-12-17 16:07   ` Jeff Layton
2021-12-17 16:05 ` [PATCH v2 1/2] ceph: Uninline the data on a file opened for writing Jeff Layton
2021-12-17 16:20 ` Matthew Wilcox
2021-12-17 17:18   ` Jeff Layton [this message]
2021-12-17 17:29     ` Matthew Wilcox

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=e2fcdecb9288dc112d0051e917da5bb48bf72388.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=ceph-devel@vger.kernel.org \
    --cc=dhowells@redhat.com \
    --cc=idryomov@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=willy@infradead.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).