Slava, On 2019/07/17 1:51, Viacheslav Dubeyko wrote: >> As mentioned previously, zonefs goal is to represent zones of a zoned >> block >> device with files, thus providing a simple abstraction one file == >> one zone and >> simplifying application implementation. And this means that the only >> sensible >> use case for zonefs is applications using large container like files. >> LSM-tree >> based applications being a very good match in this respect. >> > > > I am talking not about file size but about number of files on the > volume here. I meant that file system could easily contain about > 100,000 files on the volume. So, if every file uses 256 MB zone then > 100,000 files need in 24 TB volume. zonefs provides a different representation of the raw device. It is not abstracting it. One file is one zone. So if the use case needs more files, then another device model must be used (higher capacity or smaller zone size). It is as simple as that. >> What do you mean allocation scheme ? There is none ! one file == one >> zone and >> all files are fully provisioned and allocated on mount. zonefs does >> not allow >> the creation of files and there is no dynamic "block allocation". >> Again, please >> do not consider zonefs as a normal file system. It is closer to a raw >> block >> device interface than to a fully featured file system. >> > > OK. It sounds that a file cannot grow beyond the allocated number of > contigous zone(s) during the mount operation. Am I correct? But if a > file is needed to be resized what can be done in such case? Should it > need to re-mount the file system? In the case of sequential zone files, one file always represents a single zone. In the case of conventional zones, the default behavior is the same, and optionally one file can be a set of contiguous conventional zones. And a remount can switch between one conventional zone per file or aggregated conventional zones files. Conventional zone files have a fixed size set to the zone size. These files cannot be truncated. For sequential zone files, only truncation to 0 is possible. That is equivalent to doing a zone reset. A remount will not allow resizing the maximum size of files because that is determine by the device zone size, which is fixed and cannot be changed. > By the way, does this approach provides the way to use the device's > internal parallelism? What should anybody take into account for > exploiting the device's internal parallelism? zonefs uses the standard BIO interface which does not have any provision for exposing HW specific parallel resources. So no, there is no such feature implemented. Zoned block devices are for now SMR HDDs only anyway, and HDDs are have no parallelism. -- Damien Le Moal Western Digital Research
