public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bagas Sanjaya <bagasdotme@gmail.com>
To: David Howells <dhowells@redhat.com>
Cc: 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, 9 Apr 2025 20:54:49 +0700	[thread overview]
Message-ID: <Z_Z8KVgaH-ksEKog@archie.me> (raw)
In-Reply-To: <1676060.1744205063@warthog.procyon.org.uk>

[-- Attachment #1: Type: text/plain, Size: 3849 bytes --]

On Wed, Apr 09, 2025 at 02:24:23PM +0100, David Howells wrote:
> 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.

I prefer that above too as it is more explicit.

> 
> > > > > +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?

Oh, that's what you mean. I'm leaning toward that.

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

Thread overview: 9+ 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
2025-04-09 13:54         ` Bagas Sanjaya [this message]
2025-04-09 14:18 ` [PATCH v2] " David Howells
2025-04-11 13:24   ` Christian Brauner
  -- strict thread matches above, loose matches on Subject: below --
2025-04-09 10:10 [PATCH] " 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=Z_Z8KVgaH-ksEKog@archie.me \
    --to=bagasdotme@gmail.com \
    --cc=amarkuze@redhat.com \
    --cc=brauner@kernel.org \
    --cc=corbet@lwn.net \
    --cc=dhowells@redhat.com \
    --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