diff mbox series

[3/3] zonefs: document the explicit-open mount option

Message ID 20200904112328.28887-4-johannes.thumshirn@wdc.com (mailing list archive)
State New
Headers show
Series zonefs: introduce -o explicit-open mount option | expand

Commit Message

Johannes Thumshirn Sept. 4, 2020, 11:23 a.m. UTC
Document the newly introduced explicit-open mount option.

Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
---
 Documentation/filesystems/zonefs.rst | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

Comments

Randy Dunlap Sept. 4, 2020, 3:17 p.m. UTC | #1
Hi--

On 9/4/20 4:23 AM, Johannes Thumshirn wrote:
> Document the newly introduced explicit-open mount option.
> 
> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
> ---
>  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

I would say                   an NVMe

> +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.

          ^^ duplicate "the"

> +This potential limitation translate into a risk for applications to see

                             translates

> +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

      opened

> +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
>  =======================
>  
> 

thanks.
Damien Le Moal Sept. 7, 2020, 3:09 a.m. UTC | #2
On 2020/09/04 20:23, Johannes Thumshirn wrote:
> Document the newly introduced explicit-open mount option.
> 
> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
> ---
>  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 !
diff mbox series

Patch

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
 =======================