Btrfs Gets Big Changes, Features In Linux 3.14 Kernel

[jwilliams]

Marginally.

False. LZ4 is much faster at decompression than LZO.

[erendorn]

False. LZ4 is much faster at decompression than LZO.

is that observable with respect to disk output?

[Calinou]

For me, faster makes a less painful time redoing my operating system and transfering all of my files every 6 months.

You're doing it wrong then...


(I use ext4)

[smitty3268]

False. LZ4 is much faster at decompression than LZO.

In the workloads btrfs would use? I doubt it.

Again, like i said the first time and you conveniently snipped out of your reply: It's not likely to ever be noticed by anyone in real life, unless they are specifically staring at benchmark times.

There's lots of actual features that are far more important.

[Pajn]

Actually no, you don't need a seperate /boot partition. Or as a matter of fact, you don't need to use partitions at all if you don't want to. You can format raw block devices with btrfs, and It leaves space for grub by design.

I never use seperate /boot partitions myself. I like to leave /boot inside the /root subvolume, so it's dead simple to roll back without worrying about the /boot being out of sync with the file system.

If you actually had read his post you would see that they are about F2FS and not BTRFS.

[s_j_newbury]

This branch enables lz4 support for btrfs:
git://repo.or.cz/linux-2.6/btrfs-unstable dev/lz4-313

[Goderic]

Is there or will there be an effort to make ensure that BTRFS is as fast as or faster than EXT4? I know BTRFS is all about features rather than performance, but the average home user doesn't need all of those advanced features. For me, faster makes a less painful time redoing my operating system and transfering all of my files every 6 months.

If you don't care about the features BTRFS gives you, why don't you just stay with EXT4?

[zanny]

Ideally i'd never be needed, since you should always have new data or old data, never inconsistent data according to Btrfs' design philosophy.

Additionally no fsck tool is ever -really- 'safe and stable' since the nature of the beast is that if anything would go wrong it'd probably go VERY wrong. You can only ever have varying degrees of 'safe and stable' which everyone will have a different standard for what is good enough.


Personally I have enough faith in Btrfs to run it on a Fedora 20 home server which gets used as my centralized backup for my laptop and phone. Is there an attached eternal drive as a secondary backup? Sure, but thats formatted as NTFS so I'm taking ANOTHER risk by using Ntfs through Linux ANYWAY.

I had a power outage in the last week that corrupted inodes in a var directory. You can't delete the parent directory or anything, because it immediately crashes the FS to ro. So I just have a folder called "broken-dir" in the root of my var subvolume that contains bad inodes, where btrfsck finds them and says "nope, not fixing that" even in repair mode.

Yeah, that could happen with any filesystem, but the point of btrfs is atomic transactions to minimize that occurrence. Note how it isn't file data integrity, it is the metadata that got fudged.

[jwilliams]

In the workloads btrfs would use? I doubt it.

That is because you obviously do not know what you are talking about.

LZ4 is much faster than LZO on decompression, for a wide variety of content. The code is already in the kernel and can be used for kernel decompression. The smart move for a good project manager would be to devote a few hours of developer time to add LZ4 to btrfs.

[smitty3268]

That is because you obviously do not know what you are talking about.

LZ4 is much faster than LZO on decompression, for a wide variety of content. The code is already in the kernel and can be used for kernel decompression. The smart move for a good project manager would be to devote a few hours of developer time to add LZ4 to btrfs.

You can keep repeating yourself as much as you want, it won't change anything. There's not a shred of proof anyone would actually notice a difference by adding lz4.

Show me blind testing user studies where people are suddenly surprised by the speed difference and maybe i'll change my mind.