On 2020/02/20 10:28, Randy Dunlap wrote: > From: Randy Dunlap <rdunlap@xxxxxxxxxxxxx> > > Fix typos, spellos, etc. in zonefs.txt. > > Signed-off-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx> > Cc: Damien Le Moal <Damien.LeMoal@xxxxxxx> Applied. Thanks ! > --- > Documentation/filesystems/zonefs.txt | 20 ++++++++++---------- > 1 file changed, 10 insertions(+), 10 deletions(-) > > --- linux-next-20200219.orig/Documentation/filesystems/zonefs.txt > +++ linux-next-20200219/Documentation/filesystems/zonefs.txt > @@ -134,7 +134,7 @@ Sequential zone files can only be writte > end, that is, write operations can only be append writes. Zonefs makes no > attempt at accepting random writes and will fail any write request that has a > start offset not corresponding to the end of the file, or to the end of the last > -write issued and still in-flight (for asynchrnous I/O operations). > +write issued and still in-flight (for asynchronous I/O operations). > > Since dirty page writeback by the page cache does not guarantee a sequential > write pattern, zonefs prevents buffered writes and writeable shared mappings > @@ -142,7 +142,7 @@ on sequential files. Only direct I/O wri > zonefs relies on the sequential delivery of write I/O requests to the device > implemented by the block layer elevator. An elevator implementing the sequential > write feature for zoned block device (ELEVATOR_F_ZBD_SEQ_WRITE elevator feature) > -must be used. This type of elevator (e.g. mq-deadline) is the set by default > +must be used. This type of elevator (e.g. mq-deadline) is set by default > for zoned block devices on device initialization. > > There are no restrictions on the type of I/O used for read operations in > @@ -196,7 +196,7 @@ additional conditions that result in I/O > may still happen in the case of a partial failure of a very large direct I/O > operation split into multiple BIOs/requests or asynchronous I/O operations. > If one of the write request within the set of sequential write requests > - issued to the device fails, all write requests after queued after it will > + issued to the device fails, all write requests queued after it will > become unaligned and fail. > > * Delayed write errors: similarly to regular block devices, if the device side > @@ -207,7 +207,7 @@ additional conditions that result in I/O > causing all data to be dropped after the sector that caused the error. > > All I/O errors detected by zonefs are notified to the user with an error code > -return for the system call that trigered or detected the error. The recovery > +return for the system call that triggered or detected the error. The recovery > actions taken by zonefs in response to I/O errors depend on the I/O type (read > vs write) and on the reason for the error (bad sector, unaligned writes or zone > condition change). > @@ -222,7 +222,7 @@ condition change). > * A zone condition change to read-only or offline also always triggers zonefs > I/O error recovery. > > -Zonefs minimal I/O error recovery may change a file size and a file access > +Zonefs minimal I/O error recovery may change a file size and file access > permissions. > > * File size changes: > @@ -237,7 +237,7 @@ permissions. > A file size may also be reduced to reflect a delayed write error detected on > fsync(): in this case, the amount of data effectively written in the zone may > be less than originally indicated by the file inode size. After such I/O > - error, zonefs always fixes a file inode size to reflect the amount of data > + error, zonefs always fixes the file inode size to reflect the amount of data > persistently stored in the file zone. > > * Access permission changes: > @@ -281,11 +281,11 @@ Further notes: > permissions to read-only applies to all files. The file system is remounted > read-only. > * Access permission and file size changes due to the device transitioning zones > - to the offline condition are permanent. Remounting or reformating the device > + to the offline condition are permanent. Remounting or reformatting the device > with mkfs.zonefs (mkzonefs) will not change back offline zone files to a good > state. > * File access permission changes to read-only due to the device transitioning > - zones to the read-only condition are permanent. Remounting or reformating > + zones to the read-only condition are permanent. Remounting or reformatting > the device will not re-enable file write access. > * File access permission changes implied by the remount-ro, zone-ro and > zone-offline mount options are temporary for zones in a good condition. > @@ -301,13 +301,13 @@ Mount options > > zonefs define the "errors=<behavior>" mount option to allow the user to specify > zonefs behavior in response to I/O errors, inode size inconsistencies or zone > -condition chages. The defined behaviors are as follow: > +condition changes. The defined behaviors are as follow: > * remount-ro (default) > * zone-ro > * zone-offline > * repair > > -The I/O error actions defined for each behavior is detailed in the previous > +The I/O error actions defined for each behavior are detailed in the previous > section. > > Zonefs User Space Tools > > -- Damien Le Moal Western Digital Research
