On 2020/09/04 20:23, Johannes Thumshirn wrote: > Document the newly introduced explicit-open mount option. > > Signed-off-by: Johannes Thumshirn <johannes.thumshirn@xxxxxxx> > --- > Documentation/filesystems/zonefs.rst | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/Documentation/filesystems/zonefs.rst b/Documentation/filesystems/zonefs.rst > index 6c18bc8ce332..ff8bc3634bad 100644 > --- a/Documentation/filesystems/zonefs.rst > +++ b/Documentation/filesystems/zonefs.rst > @@ -326,6 +326,21 @@ discover the amount of data that has been written to the zone. In the case of a > read-only zone discovered at run-time, as indicated in the previous section. > The size of the zone file is left unchanged from its last updated value. > > +A zoned block device (e.g. a NVMe Zoned Namespace device) may have > +limits on the number of zones that can be active, that is, zones that > +are in the the implicit open, explicit open or closed conditions. > +This potential limitation translate into a risk for applications to see > +write IO errors due to this limit being exceeded if the zone of a file > +is not already active when a write request is issued by the user. > + > +To avoid these potential errors, the "explicit-open" mount option > +forces zones to be made active using an open zone command when a file > +is open for writing for the first time. If the zone open command > +succeeds, the application is then guaranteed that write requests can be > +processed. Conversely, the "explicit-open" mount option will result in > +a zone close command being issued to the device on the last close() of > +a zone file if the zone is not full nor empty. > + > Zonefs User Space Tools > ======================= > > Looks good. Please resend with Randy's comments addressed. Thanks ! -- Damien Le Moal Western Digital Research
