Linux 6.7 Set For Release With Bcachefs File-System, Intel Meteor Lake Graphics In Good Shape

[phoronix]

Phoronix: Linux 6.7 Set For Release With Bcachefs File-System, Intel Meteor Lake Graphics In Good Shape

The Linux 6.7 kernel is expected to be released as stable later today following the one week delay due to the end-of-year holidays. Here's a reminder about some of the best features in Linux 6.7...

https://www.phoronix.com/news/Linux-6.7-Features-Today

[alosarjos]

Hi Michael!

Do you know if they are finally enabling the capability to change voltage on AMD RDNA3 GPUs? It was an incoming feature for 6.5 if I remember correctly but last time I saw, it was delayed with 6.7 and target

[waxhead]

I am a faithful BTRFS user, but I seriously hope that BCacheFS was not merged too early (like BTRFS was), because the last thing we need is yet another filesystem where people get bitten once or twice and therefore automagically assumes forever and ever that the design sucks, and that it will forever loose data until the heat death of the universe despite all evidence saying otherwise. Not that I am much better myself , I am still scared that XFS truncates files to zero bytes every now and then.

I am crossing my fingers that BCacheFS, just like BTRFS sooner or later gets it's own status page so people know what features are safe to use and what features they should stay away from unless they want to experiment.

[geearf]

I am a faithful BTRFS user, but I seriously hope that BCacheFS was not merged too early (like BTRFS was), because the last thing we need is yet another filesystem where people get bitten once or twice and therefore automagically assumes forever and ever that the design sucks, and that it will forever loose data until the heat death of the universe despite all evidence saying otherwise. Not that I am much better myself , I am still scared that XFS truncates files to zero bytes every now and then.

I am crossing my fingers that BCacheFS, just like BTRFS sooner or later gets it's own status page so people know what features are safe to use and what features they should stay away from unless they want to experiment.

Even if it was too early, it still is in experimental so not that promising to be stable

[skeevy420]

I am a faithful BTRFS user, but I seriously hope that BCacheFS was not merged too early (like BTRFS was), because the last thing we need is yet another filesystem where people get bitten once or twice and therefore automagically assumes forever and ever that the design sucks, and that it will forever loose data until the heat death of the universe despite all evidence saying otherwise. Not that I am much better myself , I am still scared that XFS truncates files to zero bytes every now and then.

I am crossing my fingers that BCacheFS, just like BTRFS sooner or later gets it's own status page so people know what features are safe to use and what features they should stay away from unless they want to experiment.

I just hope that Bcachefs doesn't become like BTRFS where the powers that be determine that it doesn't need LZ4 because LZO was good enough. Back in the day, meaning around 2016, pre-Zstd, that position around compressors is ultimately why I switched from BTRFS to ZFS on my long-term data drive. It has never helped that when Zstd came out and was added to the kernel and BTRFS that Zstd was supposed to cover LZ4's use-cases but it was added in a way where it couldn't access the part of Zstd that allowed it to cover the LZ4 use-cases. 6-8 years later, there's still no LZ4 or the Zstd-Fast equivalent.

Perhaps BTRFS wouldn't be in its position if it didn't have bad leadership stifling innovation because the current way is good enough.

[cynic]

I just hope that Bcachefs doesn't become like BTRFS where the powers that be determine that it doesn't need LZ4 because LZO was good enough. Back in the day, meaning around 2016, pre-Zstd, that position around compressors is ultimately why I switched from BTRFS to ZFS on my long-term data drive. It has never helped that when Zstd came out and was added to the kernel and BTRFS that Zstd was supposed to cover LZ4's use-cases but it was added in a way where it couldn't access the part of Zstd that allowed it to cover the LZ4 use-cases. 6-8 years later, there's still no LZ4 or the Zstd-Fast equivalent.

Perhaps BTRFS wouldn't be in its position if it didn't have bad leadership stifling innovation because the current way is good enough.

have you ever considered that (paid) developer working on btrfs are not infinite, so they cannot implement whatever thing people desire?
free developer naturally work on whatever area they like or are interested in.

you got an entire OS for free, and are still complaining.

if you want that feature so bad you can either write it by yourself or pay someone to write it for you.

[waxhead]

I just hope that Bcachefs doesn't become like BTRFS where the powers that be determine that it doesn't need LZ4 because LZO was good enough. Back in the day, meaning around 2016, pre-Zstd, that position around compressors is ultimately why I switched from BTRFS to ZFS on my long-term data drive. It has never helped that when Zstd came out and was added to the kernel and BTRFS that Zstd was supposed to cover LZ4's use-cases but it was added in a way where it couldn't access the part of Zstd that allowed it to cover the LZ4 use-cases. 6-8 years later, there's still no LZ4 or the Zstd-Fast equivalent.

Perhaps BTRFS wouldn't be in its position if it didn't have bad leadership stifling innovation because the current way is good enough.

As far as I can remember it was not because LZO was good enough in itself, but because with the amount of data that can be "seen" by the compression algorithm. Unless I am mistaking BTRFS sees up to 128K in one go which means that it can not compress slices larger than 128k without a format change. With that limitation LZO was comparable to LZ4 and there was no need for implementing another compression algorithm without any clear benefits.
ZFS on the other hand (to my knowledge) allows compressing larger "slices" so the situation is a bit different there.

I have no clue how BCacheFS deals with this , but it will be interesting to see how it turns out.

[cynic]

I am still scared that XFS truncates files to zero bytes every now and then.

that was my nightmare on my laptop whenever I was short on battery!

[skeevy420]

have you ever considered that (paid) developer working on btrfs are not infinite, so they cannot implement whatever thing people desire?
free developer naturally work on whatever area they like or are interested in.

you got an entire OS for free, and are still complaining.

if you want that feature so bad you can either write it by yourself or pay someone to write it for you.

Yes, I have considered that. Tying to lazy-shame me doesn't change how things said on the LKML about LZO and LZ4 didn't inspire me to have future confidence in BTRFS nor has anything changed in the almost decade since for me to regain confidence in it. I know that the gains from LZO to LZ4 are minuscule, but they're gains nonetheless. If they're willing to settle there then I can't help but wonder where else they're willing to settle. It's a valid thing to wonder.

I don't want that to happen to Bcachefs. It's the first in-tree file system that I've been excited about in a long time and it seems to have a lot of enthusiasm behind it. That describes BTRFS back in the day so I'm just hoping that history doesn't repeat itself.

...and don't ask me for sources from 6 to 8 years ago.

[CommunityMember]

I just hope that Bcachefs doesn't become like BTRFS where the powers that be determine that it doesn't need LZ4 because LZO was good enough.

The "powers that be" are the people who choose to, or are paid to, contribute to Linux as a whole (and that includes the file systems).

If one is looking at who can actually make a difference, or whom decided to settle for not making a difference, look in the mirror.

I know taking out a support contract on your desktop(s) is not the majority of the Linux users way, but if more people did it they would (if they are smart about it) have a seat at the table to recommend and request improvements from their chosen distros.