Bcachefs Is Still Getting Fixed Up To Be A Next-Gen Linux File-System

[phoronix]

Phoronix: Bcachefs Is Still Getting Fixed Up To Be A Next-Gen Linux File-System

Kent Overstreet continues developing Bcachefs as what he hopes will be a next-generation Linux file-system code that's originally derived -- but now distantly removed -- from the Bcache code-base...

http://www.phoronix.com/scan.php?page=news_item&px=Bcachefs-April-2017

[microcode]

I think it's awesome that he has a patreon page for his filesystem, seems like a good way to go.

[waxhead]

While I do welcome other filesystems I ponder if not many of us slightly penguin biased people would be honking of joy if mdadm would work a bit like btrfs. e.g. allocate in chunks and allow for differently sized disks to be used in raid 1/10/5/6 and possibly beyond. Throw in datachecksum and repair and you have a filesystem agnostic layer that essentially replicates the most useful (from a efficiency/redundancy point of view) features of btrfs and bcachefs.

[ldo17]

While I do welcome other filesystems I ponder if not many of us slightly penguin biased people would be honking of joy if mdadm would work a bit like btrfs. e.g. allocate in chunks and allow for differently sized disks to be used in raid 1/10/5/6 and possibly beyond. Throw in datachecksum and repair and you have a filesystem agnostic layer that essentially replicates the most useful (from a efficiency/redundancy point of view) features of btrfs and bcachefs.

Have you looked at LVM?

[waxhead]

Have you looked at LVM?

Yes I have.

[starshipeleven]

While I do welcome other filesystems I ponder if not many of us slightly penguin biased people would be honking of joy if mdadm would work a bit like btrfs. e.g. allocate in chunks and allow for differently sized disks to be used in raid 1/10/5/6 and possibly beyond. Throw in datachecksum and repair and you have a filesystem agnostic layer that essentially replicates the most useful (from a efficiency/redundancy point of view) features of btrfs and bcachefs.

Uh... no. There is a reason those features are implemented in filesystems and not at the block layer. It's not all a RedHat Conspiracy meant to push the yet-to-be-made-public systemd-btrfs and rule the world.

Filesystem agnostic layers work at block level and thus they have no way of knowing what blocks are used and what are not, and what is in each block (and when it was changed, and so on).

So you simply can't do that, or it would work at lower performance as a filesystem implementation as it can't tell what is what so on rebuild it will have to scan the whole disk instead of looking at metadata (which is at filesystem level).
And if you try to add metadata and other stuff to deal with this, you end adding filesystem features to stuff supposed to work on block layer, so you end with what is basically a filesystem that contains your actual filesystem and that's plain stupid.
As simple as that.

[nomadewolf]

This filesystem can't come soon enough.
Looks like what Btrfs should've been, but failed...

[ermo]

This filesystem can't come soon enough.
Looks like what Btrfs should've been, but failed...

I was going to write that it would be ironic if bcachefs ends up as both an ext4/xfs AND btrfs/zfs replacement. Then again, I don't really expect it to replace xfs and zfs, as those two were grown over the years by SGI/IBM and SUN respectively.

Speaking of mdadm: I just moved my home server LVM root to a couple of older 128GB SSDs in a 2-disk mdadm RAID10 'far' layout (the nitpicky types will insist that that this is really RAID1E).

My €0.02 is that the 'far' layout is THE best mdadm layout for SSDs because it allows for striped reads across all disks and since SSDs don't suffer from the rotating disk search penalty, write speed on SSDs is the same across near/offset/far layouts.

I just tested it last night -- reading from the LV via dd gave me 1.1GB/s sustained read performance on an old AMD SB850 controller. Wow.

[waxhead]

Uh... no. There is a reason those features are implemented in filesystems and not at the block layer. It's not all a RedHat Conspiracy meant to push the yet-to-be-made-public systemd-btrfs and rule the world.

Filesystem agnostic layers work at block level and thus they have no way of knowing what blocks are used and what are not, and what is in each block (and when it was changed, and so on).

So you simply can't do that, or it would work at lower performance as a filesystem implementation as it can't tell what is what so on rebuild it will have to scan the whole disk instead of looking at metadata (which is at filesystem level).
And if you try to add metadata and other stuff to deal with this, you end adding filesystem features to stuff supposed to work on block layer, so you end with what is basically a filesystem that contains your actual filesystem and that's plain stupid.
As simple as that.

First of all, as I have stated elsewhere on this board. While I do not always like everything about systemd it does for me solve more problems than it creates so far, and I actually like it so... "sorry, wrong beat!" I am not keen on putting fuel on the fire for any stupid conspiracy theory right now. Perhaps later...

The block layer should be perfectly able to know what blocks are in use and what's not. It will however NOT know about previously used blocks that has been freed up without some magic being done by the filesystem so yes, I do understand your point, but it is possible to shrink an mdadm array and LVM essentially does everything with some limits. However this would of course require some chewing of data that is essentially similar to btrfs balance anyway. So yes, perhaps not my brightest comment in a while

[nomadewolf]

I was going to write that it would be ironic if bcachefs ends up as both an ext4/xfs AND btrfs/zfs replacement. Then again, I don't really expect it to replace xfs and zfs, as those two were grown over the years by SGI/IBM and SUN respectively.

The potential is certainly there. I just hope this doens't become another ext4 or Btrfs...