mirror of https://lore.kernel.org/lkml/
 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: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-12 18:38 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-17  0:05   ` [PATCH 0/2] New zonefs file system 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®