zonefs.rst 21 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437
  1. .. SPDX-License-Identifier: GPL-2.0
  2. ================================================
  3. ZoneFS - Zone filesystem for Zoned block devices
  4. ================================================
  5. Introduction
  6. ============
  7. zonefs is a very simple file system exposing each zone of a zoned block device
  8. as a file. Unlike a regular POSIX-compliant file system with native zoned block
  9. device support (e.g. f2fs), zonefs does not hide the sequential write
  10. constraint of zoned block devices to the user. Files representing sequential
  11. write zones of the device must be written sequentially starting from the end
  12. of the file (append only writes).
  13. As such, zonefs is in essence closer to a raw block device access interface
  14. than to a full-featured POSIX file system. The goal of zonefs is to simplify
  15. the implementation of zoned block device support in applications by replacing
  16. raw block device file accesses with a richer file API, avoiding relying on
  17. direct block device file ioctls which may be more obscure to developers. One
  18. example of this approach is the implementation of LSM (log-structured merge)
  19. tree structures (such as used in RocksDB and LevelDB) on zoned block devices
  20. by allowing SSTables to be stored in a zone file similarly to a regular file
  21. system rather than as a range of sectors of the entire disk. The introduction
  22. of the higher level construct "one file is one zone" can help reducing the
  23. amount of changes needed in the application as well as introducing support for
  24. different application programming languages.
  25. Zoned block devices
  26. -------------------
  27. Zoned storage devices belong to a class of storage devices with an address
  28. space that is divided into zones. A zone is a group of consecutive LBAs and all
  29. zones are contiguous (there are no LBA gaps). Zones may have different types.
  30. * Conventional zones: there are no access constraints to LBAs belonging to
  31. conventional zones. Any read or write access can be executed, similarly to a
  32. regular block device.
  33. * Sequential zones: these zones accept random reads but must be written
  34. sequentially. Each sequential zone has a write pointer maintained by the
  35. device that keeps track of the mandatory start LBA position of the next write
  36. to the device. As a result of this write constraint, LBAs in a sequential zone
  37. cannot be overwritten. Sequential zones must first be erased using a special
  38. command (zone reset) before rewriting.
  39. Zoned storage devices can be implemented using various recording and media
  40. technologies. The most common form of zoned storage today uses the SCSI Zoned
  41. Block Commands (ZBC) and Zoned ATA Commands (ZAC) interfaces on Shingled
  42. Magnetic Recording (SMR) HDDs.
  43. Solid State Disks (SSD) storage devices can also implement a zoned interface
  44. to, for instance, reduce internal write amplification due to garbage collection.
  45. The NVMe Zoned NameSpace (ZNS) is a technical proposal of the NVMe standard
  46. committee aiming at adding a zoned storage interface to the NVMe protocol.
  47. Zonefs Overview
  48. ===============
  49. Zonefs exposes the zones of a zoned block device as files. The files
  50. representing zones are grouped by zone type, which are themselves represented
  51. by sub-directories. This file structure is built entirely using zone information
  52. provided by the device and so does not require any complex on-disk metadata
  53. structure.
  54. On-disk metadata
  55. ----------------
  56. zonefs on-disk metadata is reduced to an immutable super block which
  57. persistently stores a magic number and optional feature flags and values. On
  58. mount, zonefs uses blkdev_report_zones() to obtain the device zone configuration
  59. and populates the mount point with a static file tree solely based on this
  60. information. File sizes come from the device zone type and write pointer
  61. position managed by the device itself.
  62. The super block is always written on disk at sector 0. The first zone of the
  63. device storing the super block is never exposed as a zone file by zonefs. If
  64. the zone containing the super block is a sequential zone, the mkzonefs format
  65. tool always "finishes" the zone, that is, it transitions the zone to a full
  66. state to make it read-only, preventing any data write.
  67. Zone type sub-directories
  68. -------------------------
  69. Files representing zones of the same type are grouped together under the same
  70. sub-directory automatically created on mount.
  71. For conventional zones, the sub-directory "cnv" is used. This directory is
  72. however created if and only if the device has usable conventional zones. If
  73. the device only has a single conventional zone at sector 0, the zone will not
  74. be exposed as a file as it will be used to store the zonefs super block. For
  75. such devices, the "cnv" sub-directory will not be created.
  76. For sequential write zones, the sub-directory "seq" is used.
  77. These two directories are the only directories that exist in zonefs. Users
  78. cannot create other directories and cannot rename nor delete the "cnv" and
  79. "seq" sub-directories.
  80. The size of the directories indicated by the st_size field of struct stat,
  81. obtained with the stat() or fstat() system calls, indicates the number of files
  82. existing under the directory.
  83. Zone files
  84. ----------
  85. Zone files are named using the number of the zone they represent within the set
  86. of zones of a particular type. That is, both the "cnv" and "seq" directories
  87. contain files named "0", "1", "2", ... The file numbers also represent
  88. increasing zone start sector on the device.
  89. All read and write operations to zone files are not allowed beyond the file
  90. maximum size, that is, beyond the zone capacity. Any access exceeding the zone
  91. capacity is failed with the -EFBIG error.
  92. Creating, deleting, renaming or modifying any attribute of files and
  93. sub-directories is not allowed.
  94. The number of blocks of a file as reported by stat() and fstat() indicates the
  95. capacity of the zone file, or in other words, the maximum file size.
  96. Conventional zone files
  97. -----------------------
  98. The size of conventional zone files is fixed to the size of the zone they
  99. represent. Conventional zone files cannot be truncated.
  100. These files can be randomly read and written using any type of I/O operation:
  101. buffered I/Os, direct I/Os, memory mapped I/Os (mmap), etc. There are no I/O
  102. constraint for these files beyond the file size limit mentioned above.
  103. Sequential zone files
  104. ---------------------
  105. The size of sequential zone files grouped in the "seq" sub-directory represents
  106. the file's zone write pointer position relative to the zone start sector.
  107. Sequential zone files can only be written sequentially, starting from the file
  108. end, that is, write operations can only be append writes. Zonefs makes no
  109. attempt at accepting random writes and will fail any write request that has a
  110. start offset not corresponding to the end of the file, or to the end of the last
  111. write issued and still in-flight (for asynchronous I/O operations).
  112. Since dirty page writeback by the page cache does not guarantee a sequential
  113. write pattern, zonefs prevents buffered writes and writeable shared mappings
  114. on sequential files. Only direct I/O writes are accepted for these files.
  115. zonefs relies on the sequential delivery of write I/O requests to the device
  116. implemented by the block layer elevator. An elevator implementing the sequential
  117. write feature for zoned block device (ELEVATOR_F_ZBD_SEQ_WRITE elevator feature)
  118. must be used. This type of elevator (e.g. mq-deadline) is set by default
  119. for zoned block devices on device initialization.
  120. There are no restrictions on the type of I/O used for read operations in
  121. sequential zone files. Buffered I/Os, direct I/Os and shared read mappings are
  122. all accepted.
  123. Truncating sequential zone files is allowed only down to 0, in which case, the
  124. zone is reset to rewind the file zone write pointer position to the start of
  125. the zone, or up to the zone capacity, in which case the file's zone is
  126. transitioned to the FULL state (finish zone operation).
  127. Format options
  128. --------------
  129. Several optional features of zonefs can be enabled at format time.
  130. * Conventional zone aggregation: ranges of contiguous conventional zones can be
  131. aggregated into a single larger file instead of the default one file per zone.
  132. * File ownership: The owner UID and GID of zone files is by default 0 (root)
  133. but can be changed to any valid UID/GID.
  134. * File access permissions: the default 640 access permissions can be changed.
  135. IO error handling
  136. -----------------
  137. Zoned block devices may fail I/O requests for reasons similar to regular block
  138. devices, e.g. due to bad sectors. However, in addition to such known I/O
  139. failure pattern, the standards governing zoned block devices behavior define
  140. additional conditions that result in I/O errors.
  141. * A zone may transition to the read-only condition (BLK_ZONE_COND_READONLY):
  142. While the data already written in the zone is still readable, the zone can
  143. no longer be written. No user action on the zone (zone management command or
  144. read/write access) can change the zone condition back to a normal read/write
  145. state. While the reasons for the device to transition a zone to read-only
  146. state are not defined by the standards, a typical cause for such transition
  147. would be a defective write head on an HDD (all zones under this head are
  148. changed to read-only).
  149. * A zone may transition to the offline condition (BLK_ZONE_COND_OFFLINE):
  150. An offline zone cannot be read nor written. No user action can transition an
  151. offline zone back to an operational good state. Similarly to zone read-only
  152. transitions, the reasons for a drive to transition a zone to the offline
  153. condition are undefined. A typical cause would be a defective read-write head
  154. on an HDD causing all zones on the platter under the broken head to be
  155. inaccessible.
  156. * Unaligned write errors: These errors result from the host issuing write
  157. requests with a start sector that does not correspond to a zone write pointer
  158. position when the write request is executed by the device. Even though zonefs
  159. enforces sequential file write for sequential zones, unaligned write errors
  160. may still happen in the case of a partial failure of a very large direct I/O
  161. operation split into multiple BIOs/requests or asynchronous I/O operations.
  162. If one of the write request within the set of sequential write requests
  163. issued to the device fails, all write requests queued after it will
  164. become unaligned and fail.
  165. * Delayed write errors: similarly to regular block devices, if the device side
  166. write cache is enabled, write errors may occur in ranges of previously
  167. completed writes when the device write cache is flushed, e.g. on fsync().
  168. Similarly to the previous immediate unaligned write error case, delayed write
  169. errors can propagate through a stream of cached sequential data for a zone
  170. causing all data to be dropped after the sector that caused the error.
  171. All I/O errors detected by zonefs are notified to the user with an error code
  172. return for the system call that triggered or detected the error. The recovery
  173. actions taken by zonefs in response to I/O errors depend on the I/O type (read
  174. vs write) and on the reason for the error (bad sector, unaligned writes or zone
  175. condition change).
  176. * For read I/O errors, zonefs does not execute any particular recovery action,
  177. but only if the file zone is still in a good condition and there is no
  178. inconsistency between the file inode size and its zone write pointer position.
  179. If a problem is detected, I/O error recovery is executed (see below table).
  180. * For write I/O errors, zonefs I/O error recovery is always executed.
  181. * A zone condition change to read-only or offline also always triggers zonefs
  182. I/O error recovery.
  183. Zonefs minimal I/O error recovery may change a file size and file access
  184. permissions.
  185. * File size changes:
  186. Immediate or delayed write errors in a sequential zone file may cause the file
  187. inode size to be inconsistent with the amount of data successfully written in
  188. the file zone. For instance, the partial failure of a multi-BIO large write
  189. operation will cause the zone write pointer to advance partially, even though
  190. the entire write operation will be reported as failed to the user. In such
  191. case, the file inode size must be advanced to reflect the zone write pointer
  192. change and eventually allow the user to restart writing at the end of the
  193. file.
  194. A file size may also be reduced to reflect a delayed write error detected on
  195. fsync(): in this case, the amount of data effectively written in the zone may
  196. be less than originally indicated by the file inode size. After such I/O
  197. error, zonefs always fixes the file inode size to reflect the amount of data
  198. persistently stored in the file zone.
  199. * Access permission changes:
  200. A zone condition change to read-only is indicated with a change in the file
  201. access permissions to render the file read-only. This disables changes to the
  202. file attributes and data modification. For offline zones, all permissions
  203. (read and write) to the file are disabled.
  204. Further action taken by zonefs I/O error recovery can be controlled by the user
  205. with the "errors=xxx" mount option. The table below summarizes the result of
  206. zonefs I/O error processing depending on the mount option and on the zone
  207. conditions::
  208. +--------------+-----------+-----------------------------------------+
  209. | | | Post error state |
  210. | "errors=xxx" | device | access permissions |
  211. | mount | zone | file file device zone |
  212. | option | condition | size read write read write |
  213. +--------------+-----------+-----------------------------------------+
  214. | | good | fixed yes no yes yes |
  215. | remount-ro | read-only | as is yes no yes no |
  216. | (default) | offline | 0 no no no no |
  217. +--------------+-----------+-----------------------------------------+
  218. | | good | fixed yes no yes yes |
  219. | zone-ro | read-only | as is yes no yes no |
  220. | | offline | 0 no no no no |
  221. +--------------+-----------+-----------------------------------------+
  222. | | good | 0 no no yes yes |
  223. | zone-offline | read-only | 0 no no yes no |
  224. | | offline | 0 no no no no |
  225. +--------------+-----------+-----------------------------------------+
  226. | | good | fixed yes yes yes yes |
  227. | repair | read-only | as is yes no yes no |
  228. | | offline | 0 no no no no |
  229. +--------------+-----------+-----------------------------------------+
  230. Further notes:
  231. * The "errors=remount-ro" mount option is the default behavior of zonefs I/O
  232. error processing if no errors mount option is specified.
  233. * With the "errors=remount-ro" mount option, the change of the file access
  234. permissions to read-only applies to all files. The file system is remounted
  235. read-only.
  236. * Access permission and file size changes due to the device transitioning zones
  237. to the offline condition are permanent. Remounting or reformatting the device
  238. with mkfs.zonefs (mkzonefs) will not change back offline zone files to a good
  239. state.
  240. * File access permission changes to read-only due to the device transitioning
  241. zones to the read-only condition are permanent. Remounting or reformatting
  242. the device will not re-enable file write access.
  243. * File access permission changes implied by the remount-ro, zone-ro and
  244. zone-offline mount options are temporary for zones in a good condition.
  245. Unmounting and remounting the file system will restore the previous default
  246. (format time values) access rights to the files affected.
  247. * The repair mount option triggers only the minimal set of I/O error recovery
  248. actions, that is, file size fixes for zones in a good condition. Zones
  249. indicated as being read-only or offline by the device still imply changes to
  250. the zone file access permissions as noted in the table above.
  251. Mount options
  252. -------------
  253. zonefs define the "errors=<behavior>" mount option to allow the user to specify
  254. zonefs behavior in response to I/O errors, inode size inconsistencies or zone
  255. condition changes. The defined behaviors are as follow:
  256. * remount-ro (default)
  257. * zone-ro
  258. * zone-offline
  259. * repair
  260. The run-time I/O error actions defined for each behavior are detailed in the
  261. previous section. Mount time I/O errors will cause the mount operation to fail.
  262. The handling of read-only zones also differs between mount-time and run-time.
  263. If a read-only zone is found at mount time, the zone is always treated in the
  264. same manner as offline zones, that is, all accesses are disabled and the zone
  265. file size set to 0. This is necessary as the write pointer of read-only zones
  266. is defined as invalib by the ZBC and ZAC standards, making it impossible to
  267. discover the amount of data that has been written to the zone. In the case of a
  268. read-only zone discovered at run-time, as indicated in the previous section.
  269. The size of the zone file is left unchanged from its last updated value.
  270. A zoned block device (e.g. an NVMe Zoned Namespace device) may have limits on
  271. the number of zones that can be active, that is, zones that are in the
  272. implicit open, explicit open or closed conditions. This potential limitation
  273. translates into a risk for applications to see write IO errors due to this
  274. limit being exceeded if the zone of a file is not already active when a write
  275. request is issued by the user.
  276. To avoid these potential errors, the "explicit-open" mount option forces zones
  277. to be made active using an open zone command when a file is opened for writing
  278. for the first time. If the zone open command succeeds, the application is then
  279. guaranteed that write requests can be processed. Conversely, the
  280. "explicit-open" mount option will result in a zone close command being issued
  281. to the device on the last close() of a zone file if the zone is not full nor
  282. empty.
  283. Zonefs User Space Tools
  284. =======================
  285. The mkzonefs tool is used to format zoned block devices for use with zonefs.
  286. This tool is available on Github at:
  287. https://github.com/damien-lemoal/zonefs-tools
  288. zonefs-tools also includes a test suite which can be run against any zoned
  289. block device, including null_blk block device created with zoned mode.
  290. Examples
  291. --------
  292. The following formats a 15TB host-managed SMR HDD with 256 MB zones
  293. with the conventional zones aggregation feature enabled::
  294. # mkzonefs -o aggr_cnv /dev/sdX
  295. # mount -t zonefs /dev/sdX /mnt
  296. # ls -l /mnt/
  297. total 0
  298. dr-xr-xr-x 2 root root 1 Nov 25 13:23 cnv
  299. dr-xr-xr-x 2 root root 55356 Nov 25 13:23 seq
  300. The size of the zone files sub-directories indicate the number of files
  301. existing for each type of zones. In this example, there is only one
  302. conventional zone file (all conventional zones are aggregated under a single
  303. file)::
  304. # ls -l /mnt/cnv
  305. total 137101312
  306. -rw-r----- 1 root root 140391743488 Nov 25 13:23 0
  307. This aggregated conventional zone file can be used as a regular file::
  308. # mkfs.ext4 /mnt/cnv/0
  309. # mount -o loop /mnt/cnv/0 /data
  310. The "seq" sub-directory grouping files for sequential write zones has in this
  311. example 55356 zones::
  312. # ls -lv /mnt/seq
  313. total 14511243264
  314. -rw-r----- 1 root root 0 Nov 25 13:23 0
  315. -rw-r----- 1 root root 0 Nov 25 13:23 1
  316. -rw-r----- 1 root root 0 Nov 25 13:23 2
  317. ...
  318. -rw-r----- 1 root root 0 Nov 25 13:23 55354
  319. -rw-r----- 1 root root 0 Nov 25 13:23 55355
  320. For sequential write zone files, the file size changes as data is appended at
  321. the end of the file, similarly to any regular file system::
  322. # dd if=/dev/zero of=/mnt/seq/0 bs=4096 count=1 conv=notrunc oflag=direct
  323. 1+0 records in
  324. 1+0 records out
  325. 4096 bytes (4.1 kB, 4.0 KiB) copied, 0.00044121 s, 9.3 MB/s
  326. # ls -l /mnt/seq/0
  327. -rw-r----- 1 root root 4096 Nov 25 13:23 /mnt/seq/0
  328. The written file can be truncated to the zone size, preventing any further
  329. write operation::
  330. # truncate -s 268435456 /mnt/seq/0
  331. # ls -l /mnt/seq/0
  332. -rw-r----- 1 root root 268435456 Nov 25 13:49 /mnt/seq/0
  333. Truncation to 0 size allows freeing the file zone storage space and restart
  334. append-writes to the file::
  335. # truncate -s 0 /mnt/seq/0
  336. # ls -l /mnt/seq/0
  337. -rw-r----- 1 root root 0 Nov 25 13:49 /mnt/seq/0
  338. Since files are statically mapped to zones on the disk, the number of blocks
  339. of a file as reported by stat() and fstat() indicates the capacity of the file
  340. zone::
  341. # stat /mnt/seq/0
  342. File: /mnt/seq/0
  343. Size: 0 Blocks: 524288 IO Block: 4096 regular empty file
  344. Device: 870h/2160d Inode: 50431 Links: 1
  345. Access: (0640/-rw-r-----) Uid: ( 0/ root) Gid: ( 0/ root)
  346. Access: 2019-11-25 13:23:57.048971997 +0900
  347. Modify: 2019-11-25 13:52:25.553805765 +0900
  348. Change: 2019-11-25 13:52:25.553805765 +0900
  349. Birth: -
  350. The number of blocks of the file ("Blocks") in units of 512B blocks gives the
  351. maximum file size of 524288 * 512 B = 256 MB, corresponding to the device zone
  352. capacity in this example. Of note is that the "IO block" field always
  353. indicates the minimum I/O size for writes and corresponds to the device
  354. physical sector size.