Re: [PATCH 09/21] xfs: remove the xfile_pread/pwrite APIs

Darrick J. Wong
2024-01-26T16:48:00Z

On Fri, Jan 26, 2024 at 04:21:52PM +0000, Matthew Wilcox wrote:
> On Fri, Jan 26, 2024 at 02:28:51PM +0100, Christoph Hellwig wrote:
> > +++ b/Documentation/filesystems/xfs/xfs-online-fsck-design.rst
> > @@ -1915,19 +1915,13 @@ four of those five higher level data structures.
> > The fifth use case is discussed in the :ref:`realtime summary <rtsummary>` case
> > study.
> >
> > -The most general storage interface supported by the xfile enables the reading
> > -and writing of arbitrary quantities of data at arbitrary offsets in the xfile.
> > -This capability is provided by ``xfile_pread`` and ``xfile_pwrite`` functions,
> > -which behave similarly to their userspace counterparts.
> > XFS is very record-based, which suggests that the ability to load and store
> > complete records is important.
> > To support these cases, a pair of ``xfile_obj_load`` and ``xfile_obj_store``

Nit: s/xfile_obj_XXXX/xfile_XXXX/ here.

> > -functions are provided to read and persist objects into an xfile.
> > -They are internally the same as pread and pwrite, except that they treat any
> > -error as an out of memory error.
> > +functions are provided to read and persist objects into an xfile that unlike
> > +the pread and pwrite system calls treat any error as an out of memory error.
>
> It's a bit weird to refer to the pread and pwrite system calls now.
> I'd just say:
>
> +functions are provided to read and persist objects into an xfile that
> +treat any error as an out of memory error.
>
> I wonder if we shouldn't also change:
>
> -Programmatic access (e.g. pread and pwrite) uses this mechanism.
> +Object load and store use this mechanism.

Yes.

--D