All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
To: Damien Le Moal <damien.lemoal@wdc.com>,
	linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: Johannes Thumshirn <jth@kernel.org>,
	Naohiro Aota <naohiro.aota@wdc.com>,
	"Darrick J . Wong" <darrick.wong@oracle.com>,
	Hannes Reinecke <hare@suse.de>
Subject: Re: [PATCH 0/2] New zonefs file system
Date: Mon, 16 Dec 2019 09:18:23 +0100	[thread overview]
Message-ID: <29fb138e-e9e5-5905-5422-4454c956e685@metux.net> (raw)
In-Reply-To: <20191212183816.102402-1-damien.lemoal@wdc.com>

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 ?

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 ?

Assuming you're working ontop of standard block devices anyways (instead
of tape-like media ;-)) - why introducing such a limitation ?

> 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@metux.net -- +49-151-27565287

  parent reply	other threads:[~2019-12-16  8:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-12 18:38 [PATCH 0/2] New zonefs file system Damien Le Moal
2019-12-12 18:38 ` [PATCH 1/2] fs: " Damien Le Moal
2019-12-16  8:36   ` Hannes Reinecke
2019-12-17  0:20     ` Damien Le Moal
2019-12-17  7:28       ` Hannes Reinecke
2019-12-12 18:38 ` [PATCH 2/2] zonefs: Add documentation Damien Le Moal
2019-12-16  8:38   ` Hannes Reinecke
2019-12-17  0:20     ` Damien Le Moal
2019-12-16  8:18 ` Enrico Weigelt, metux IT consult [this message]
2019-12-16  9:35   ` [PATCH 0/2] New zonefs file system Carlos Maiolino
2019-12-16  9:42     ` Carlos Maiolino
2019-12-17  0:26       ` Damien Le Moal
2019-12-17 13:05         ` Enrico Weigelt, metux IT consult
2019-12-18  1:09           ` Damien Le Moal
2019-12-17 12:33     ` Enrico Weigelt, metux IT consult
2019-12-18  0:57       ` Damien Le Moal
2019-12-17  0:05   ` Damien Le Moal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=29fb138e-e9e5-5905-5422-4454c956e685@metux.net \
    --to=lkml@metux.net \
    --cc=damien.lemoal@wdc.com \
    --cc=darrick.wong@oracle.com \
    --cc=hare@suse.de \
    --cc=jth@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=naohiro.aota@wdc.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.