On 08/31, Randy Dunlap wrote: > Change occurrences of "it's" that are possessive to "its" > so that they don't read as "it is". > > For f2fs.rst, reword one description for better clarity. > > Signed-off-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx> > Cc: Jonathan Corbet <corbet@xxxxxxx> > Cc: linux-fsdevel@xxxxxxxxxxxxxxx > Cc: linux-f2fs-devel@xxxxxxxxxxxxxxxxxxxxx > Cc: linux-xfs@xxxxxxxxxxxxxxx > Cc: Christian Brauner <brauner@xxxxxxxxxx> > Cc: Seth Forshee <sforshee@xxxxxxxxxx> > Cc: Al Viro <viro@xxxxxxxxxxxxxxxxxx> > Cc: Theodore Ts'o <tytso@xxxxxxx> > Cc: Jaegeuk Kim <jaegeuk@xxxxxxxxxx> > Reviewed-by: Darrick J. Wong <djwong@xxxxxxxxxx> > Reviewed-by: "Christian Brauner (Microsoft)" <brauner@xxxxxxxxxx> Thanks, for f2fs part. Reviewed-by: Jaegeuk Kim <jaegeuk@xxxxxxxxxx> > --- > v2: Reword the compress_log_size description. > Rebase (the xfs file changed). > Add Reviewed-by: tags. > > Thanks for Al and Ted for suggesting rewording the f2fs.rst description. > > Documentation/filesystems/f2fs.rst | 5 ++--- > Documentation/filesystems/idmappings.rst | 2 +- > Documentation/filesystems/qnx6.rst | 2 +- > Documentation/filesystems/xfs-delayed-logging-design.rst | 6 +++--- > 4 files changed, 7 insertions(+), 8 deletions(-) > > --- a/Documentation/filesystems/f2fs.rst > +++ b/Documentation/filesystems/f2fs.rst > @@ -286,9 +286,8 @@ compress_algorithm=%s:%d Control compres > algorithm level range > lz4 3 - 16 > zstd 1 - 22 > -compress_log_size=%u Support configuring compress cluster size, the size will > - be 4KB * (1 << %u), 16KB is minimum size, also it's > - default size. > +compress_log_size=%u Support configuring compress cluster size. The size will > + be 4KB * (1 << %u). The default and minimum sizes are 16KB. > compress_extension=%s Support adding specified extension, so that f2fs can enable > compression on those corresponding files, e.g. if all files > with '.ext' has high compression rate, we can set the '.ext' > --- a/Documentation/filesystems/idmappings.rst > +++ b/Documentation/filesystems/idmappings.rst > @@ -661,7 +661,7 @@ idmappings:: > mount idmapping: u0:k10000:r10000 > > Assume a file owned by ``u1000`` is read from disk. The filesystem maps this id > -to ``k21000`` according to it's idmapping. This is what is stored in the > +to ``k21000`` according to its idmapping. This is what is stored in the > inode's ``i_uid`` and ``i_gid`` fields. > > When the caller queries the ownership of this file via ``stat()`` the kernel > --- a/Documentation/filesystems/qnx6.rst > +++ b/Documentation/filesystems/qnx6.rst > @@ -176,7 +176,7 @@ Then userspace. > The requirement for a static, fixed preallocated system area comes from how > qnx6fs deals with writes. > > -Each superblock got it's own half of the system area. So superblock #1 > +Each superblock got its own half of the system area. So superblock #1 > always uses blocks from the lower half while superblock #2 just writes to > blocks represented by the upper half bitmap system area bits. > > --- a/Documentation/filesystems/xfs-delayed-logging-design.rst > +++ b/Documentation/filesystems/xfs-delayed-logging-design.rst > @@ -551,14 +551,14 @@ Essentially, this shows that an item tha > and relogged, so any tracking must be separate to the AIL infrastructure. As > such, we cannot reuse the AIL list pointers for tracking committed items, nor > can we store state in any field that is protected by the AIL lock. Hence the > -committed item tracking needs it's own locks, lists and state fields in the log > +committed item tracking needs its own locks, lists and state fields in the log > item. > > Similar to the AIL, tracking of committed items is done through a new list > called the Committed Item List (CIL). The list tracks log items that have been > committed and have formatted memory buffers attached to them. It tracks objects > in transaction commit order, so when an object is relogged it is removed from > -it's place in the list and re-inserted at the tail. This is entirely arbitrary > +its place in the list and re-inserted at the tail. This is entirely arbitrary > and done to make it easy for debugging - the last items in the list are the > ones that are most recently modified. Ordering of the CIL is not necessary for > transactional integrity (as discussed in the next section) so the ordering is > @@ -884,7 +884,7 @@ pin the object the first time it is inse > the CIL during a transaction commit, then we do not pin it again. Because there > can be multiple outstanding checkpoint contexts, we can still see elevated pin > counts, but as each checkpoint completes the pin count will retain the correct > -value according to it's context. > +value according to its context. > > Just to make matters slightly more complex, this checkpoint level context > for the pin count means that the pinning of an item must take place under the
