Hi, Damien, Thanks for your well-considered response. Damien Le Moal <Damien.LeMoal@xxxxxxx> writes: > Jeff, > > On 2019/07/18 23:11, Jeff Moyer wrote: >> Hi, Damien, >> >> Did you consider creating a shared library? I bet that would also >> ease application adoption for the use cases you're interested in, and >> would have similar performance. >> >> -Jeff > > Yes, it would, but to a lesser extent since system calls would need to be > replaced with library calls. Earlier work on LevelDB by Ting used the library > approach with libzbc, not quite a "libzonefs" but close enough. Working with > LevelDB code gave me the idea for zonefs. Compared to a library, the added > benefits are that specific language bindings are not a problem and further > simplify the code changes needed to support zoned block devices. In the case of > LevelDB for instance, C++ is used and file accesses are using streams, which > makes using a library a little difficult, and necessitates more changes just for > the internal application API itself. The needed changes spread beyond the device > access API. > > This is I think the main advantage of this simple in-kernel FS over a library: > the developer can focus on zone block device specific needs (write sequential > pattern and garbage collection) and forget about the device access parts as the > standard system calls API can be used. OK, I can see how a file system eases adoption across multiple languages, and may, in some cases, be easier to adopt by applications. However, I'm not a fan of the file system interface for this usage. Once you present a file system, there are certain expectations from users, and this fs breaks most of them. I'll throw out another suggestion that may or may not work (I haven't given it much thought). Would it be possible to create a device mapper target that would export each zone as a separate block device? I understand that wouldn't help with the write pointer management, but it would allow you to create a single "file" for each zone. > Another approach I considered is using FUSE, but went for a regular (albeit > simple) in-kernel approach due to performance concerns. While any difference in > performance for SMR HDDs would probably not be noticeable, performance would > likely be lower for upcoming NVMe zonenamespace devices compared to the > in-kernel approach. > > But granted, most of the arguments I can put forward for an in-kernel FS > solution vs a user shared library solution are mostly subjective. I think though > that having support directly provided by the kernel brings zoned block devices > into the "mainstream storage options" rather than having them perceived as > fringe solutions that need additional libraries to work correctly. Zoned block > devices are not going away and may in fact become more mainstream as > implementing higher capacities more and more depends on the sequential write > interface. A file system like this would further cement in my mind that zoned block devices are not maintstream storage options. I guess this part is highly subjective. :) Cheers, Jeff
