On Mon, Dec 16, 2019 at 09:18:23AM +0100, Enrico Weigelt, metux IT consult wrote: > On 12.12.19 19:38, Damien Le Moal wrote: > > Hi, > > > zonefs is a very simple file system exposing each zone of a zoned block > > device as a file. Unlike a regular file system with zoned block device > > support (e.g. f2fs or the on-going btrfs effort), zonefs does not hide > > the sequential write constraint of zoned block devices to the user. > > Just curious: what's the exact definition of "zoned" here ? > Something like partitions ? Zones inside a SMR HDD. > > Can these files then also serve as block devices for other filesystems ? > Just a funny idea: could we handle partitions by a file system ? > > Even more funny idea: give file systems block device ops, so they can > be directly used as such (w/o explicitly using loopdev) ;-) > > > Files representing sequential write zones of the device must be written > > sequentially starting from the end of the file (append only writes). > > So, these files can only be accessed like a tape ? On a SMR HDD, each zone can only be written sequentially, due to physics constraints. I won't post any link with references because I think majordomo will spam my email if I do, but do a google search of something like 'SMR HDD zones' and you'll get a better idea > > Assuming you're working ontop of standard block devices anyways (instead > of tape-like media ;-)) - why introducing such a limitation ? The limitation is already there on SMR drives, some of them (Device Managed models), just hide it from the system. > > > zonefs is not a POSIX compliant file system. It's goal is to simplify > > the implementation of zoned block devices support in applications by > > replacing raw block device file accesses with a richer file based API, > > avoiding relying on direct block device file ioctls which may > > be more obscure to developers. > > ioctls ? > > Last time I checked, block devices could be easily accessed via plain > file ops (read, write, seek, ...). You can basically treat them just > like big files of fixed size. > > > One example of this approach is the > > implementation of LSM (log-structured merge) tree structures (such as > > used in RocksDB and LevelDB) > > The same LevelDB as used eg. in Chrome browser, which destroys itself > every time a little temporary problem (eg. disk full) occours ? > If that's the usecase I'd rather use an simple in-memory table instead > and and enough swap, as leveldb isn't reliable enough for persistent > data anyways :p > > > on zoned block devices by allowing SSTables > > to be stored in a zone file similarly to a regular file system rather > > than as a range of sectors of a zoned device. The introduction of the > > higher level construct "one file is one zone" can help reducing the > > amount of changes needed in the application while at the same time > > allowing the use of zoned block devices with various programming > > languages other than C. > > Why not just simply use files on a suited filesystem (w/ low block io > overhead) or LVM volumes ? > > > --mtx > > -- > Dringender Hinweis: aufgrund existenzieller Bedrohung durch "Emotet" > sollten Sie *niemals* MS-Office-Dokumente via E-Mail annehmen/öffenen, > selbst wenn diese von vermeintlich vertrauenswürdigen Absendern zu > stammen scheinen. Andernfalls droht Totalschaden. > --- > Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert > werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren > GPG/PGP-Schlüssel zu. > --- > Enrico Weigelt, metux IT consult > Free software and Linux embedded engineering > info@xxxxxxxxx -- +49-151-27565287 > -- Carlos
