Re: [PATCH 0/2] New zonefs file system

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux