lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Sat, 22 Aug 2015 14:33:47 -0700
From:	Vyacheslav Dubeyko <slava@...eyko.com>
To:	Kent Overstreet <kent.overstreet@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-bcache@...r.kernel.org, sviatoslavpestov@...il.com,
	mrubin@...gle.com, zab@...bo.net, bcrl@...ck.org, ric@...hat.com,
	Vyacheslav.Dubeyko@...t.com, Cyril Guyot <cyril.guyot@...t.com>,
	adam.manzanares@...t.com, damien.lemoal@...t.com
Subject: Re: [ANNOUNCE] bcachefs - a general purpose COW filesystem

Hi Kent,

On Thu, 2015-08-20 at 21:25 -0800, Kent Overstreet wrote:
> For those who haven't kept up with bcache, the bcache codebase has been
> evolving/metastasizing into a full blown, general purpose posix filesystem - a
> modern COW filesystem with checksumming, compression, multiple devices, caching,
> and eventually snapshots and all kinds of other nifty features.
> 
> "Yet another new filesystem? Why?"
> 
> Well, years ago (going back to when I was still at Google), I and the other
> people working on bcache realized that what we were working on was, almost by
> accident, a good chunk of the functionality of a full blown filesystem - and
> there was a really clean and elegant design to be had there if we took it and
> ran with it. And a fast one - the main goal of bcachefs to match ext4 and xfs on
> performance and reliability, but with the features of btrfs/zfs.
> 

<snip>

> 
> PLANNED FEATURES:
>  - snapshots (might start on this soon)
>  - erasure coding

What erasure coding scheme(s) do you like to use?

>  - native support for SMR drives, raw flash

How do you imagine SMR drives support? How do you feel about libzbc [1]
using for SMR drives support? I am not very familiar with bcachefs
architecture yet. But I suppose that maybe libzbc model can be useful
for SMR drives support on bcachefs side. Anyway, it makes sense to
discuss proper model.

How do you imagine raw flash support in bcachefs architecture? Frankly
speaking, I am implementing NAND flash oriented file system. But this
project is proprietary yet and I can't share any details. However,
currently, I've implemented NAND flash related approaches in my file
system only. So, maybe, it make sense to consider some joint variant of
bcachefs and implementation on my side for NAND flash support. I need to
be more familiar with bcachefs architecture for such decision. But,
unfortunately, I suspect that it can be not so easy to support raw flash
for bcachefs. Of course, I can be wrong.

[1] https://github.com/hgst/libzbc

Thanks,
Vyacheslav Dubeyko.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ