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 --]
next prev parent 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