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
