public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Bagas Sanjaya <bagasdotme@gmail.com>
Cc: dhowells@redhat.com, Christian Brauner <brauner@kernel.org>,
	Paulo Alcantara <pc@manguebit.com>,
	Jeff Layton <jlayton@kernel.org>,
	Viacheslav Dubeyko <slava@dubeyko.com>,
	Alex Markuze <amarkuze@redhat.com>,
	Timothy Day <timday@amazon.com>, Jonathan Corbet <corbet@lwn.net>,
	netfs@lists.linux.dev, linux-doc@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] netfs: Update main API document
Date: Wed, 09 Apr 2025 14:24:23 +0100	[thread overview]
Message-ID: <1676060.1744205063@warthog.procyon.org.uk> (raw)
In-Reply-To: <Z_ZHoCgi2BY5lVjN@archie.me>

Bagas Sanjaya <bagasdotme@gmail.com> wrote:

> > > > +Further, if a read from the cache fails, the library will ask the filesystem to
> > > > +do the read instead, renegotiating and retiling the subrequests as necessary.
> > > Read from the filesystem itself or direct read?
> > 
> > I'm not sure what you mean.  Here, I'm talking about read subrequests - i.e. a
> > subrequest that corresponds to a BIO issued to the cache or a single RPC
> > issued to the server.  Things like DIO and pagecache are at a higher level and
> > not directly exposed to the filesystem.
> > 
> > Maybe I should amend the text to read:
> > 
> > 	Further, if one or more subrequests issued to read from the cache
> > 	fail, the library will issue them to the filesystem instead,
> > 	renegotiating and retiling the subrequests as necessary.
> 
> That one sounds better to me.

I think I like this better:

	Further, if one or more contiguous cache-read subrequests fail, the
	library will pass them to the filesystem to perform instead,
	renegotiating and retiling them as necessary to fit with the
	filesystem's parameters rather than those of the cache.

> > > > +Netfslib will pin resources on an inode for future writeback (such as pinning
> > > > +use of an fscache cookie) when an inode is dirtied.  However, this needs
> > > > +managing.  Firstly, a function is provided to unpin the writeback in
> > > inode management?
> > > > +``->write_inode()``::
> > 
> > Is "inode management" meant to be a suggested insertion or an alternative for
> > the subsection title?
> 
> I mean "However, this needs managing the inode (inode management)". Is it
> correct to you?

Um.  "However, this needs managing the inode (inode management)" isn't valid
English and "(inode management)" is superfluous with "managing the inode" also
in the sentence.

How about:

	Netfslib will pin resources on an inode for future writeback (such as pinning
	use of an fscache cookie) when an inode is dirtied.  However, this pinning
	needs careful management.  To manage the pinning, the following sequence
	occurs:

	 1) An inode state flag ``I_PINNING_NETFS_WB`` is set by netfslib when the
	    pinning begins (when a folio is dirtied, for example) if the cache is
	    active to stop the cache structures from being discarded and the cache
	    space from being culled.  This also prevents re-getting of cache resources
	    if the flag is already set.

	 2) This flag then cleared inside the inode lock during inode writeback in the
	    VM - and the fact that it was set is transferred to ``->unpinned_netfs_wb``
	    in ``struct writeback_control``.

	 3) If ``->unpinned_netfs_wb`` is now set, the write_inode procedure is forced.

	 4) The filesystem's ``->write_inode()`` function is invoked to do the cleanup.

	 5) The filesystem invokes netfs to do its cleanup.

	To do the cleanup, netfslib provides a function to do the resource unpinning::

		int netfs_unpin_writeback(struct inode *inode, struct writeback_control *wbc);

	If the filesystem doesn't need to do anything else, this may be set as a its
	``.write_inode`` method.

	Further, if an inode is deleted, the filesystem's write_inode method may not
	get called, so::

		void netfs_clear_inode_writeback(struct inode *inode, const void *aux);

	must be called from ``->evict_inode()`` *before* ``clear_inode()`` is called.


instead?

Thanks,
David


  reply	other threads:[~2025-04-09 13:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-08 15:09 [PATCH] netfs: Update main API document David Howells
2025-04-09  1:34 ` Bagas Sanjaya
2025-04-09  9:05   ` David Howells
2025-04-09 10:10     ` Bagas Sanjaya
2025-04-09 13:24       ` David Howells [this message]
2025-04-09 13:54         ` Bagas Sanjaya
2025-04-09 14:18 ` [PATCH v2] " David Howells
2025-04-11 13:24   ` Christian Brauner

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=1676060.1744205063@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=amarkuze@redhat.com \
    --cc=bagasdotme@gmail.com \
    --cc=brauner@kernel.org \
    --cc=corbet@lwn.net \
    --cc=jlayton@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netfs@lists.linux.dev \
    --cc=pc@manguebit.com \
    --cc=slava@dubeyko.com \
    --cc=timday@amazon.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