If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

It will and it has reduced the number of bugs from where it would be if there was no automatic or manual testing, both of which every major filesystem in Linux has. Several major vendors (Red Hat, Oracle, Novell) including an entire storage company (Fusion IO) which has hired several of the Btrfs developers do this because their entire business depends on this capability.

Comment

BTRFS has a serious Achilles heel and... ironically its COW & snapshots...
Every time a snapshot is made, it?s b-tree changes, and when it changes, that forces the entire file system structure (b+tree) to be modified and duplicated on each file system snapshot.
So that creates an exponential degradation each and every time a snapshot is performed simply because its COW feature is working against it really badly.
So... the very benefit BTRFS has as its best feature its always defended for(snapshots) completely makes the file system into a ticking data-time-bomb until there?s an exponential metadata overload to the point of a grinding halt and system freeze, just because there are too many nodes created by the snapshots which cause that exponential b-tree node duplication.
This is a very serious reason to NOT USE BTRFS AS DEFAULT BECAUSE ALL BTRFS FILE SYSTEMS WILL NEED TO BE DESTROYED AND RECREATED IF/WHEN THIS PROBLEM IS EVER SOLVED.
Also, all the REAL databases like Postgres, Oracle, MSSQL and MySQL etc, have realized that the only true way to be consistent and able to not be insane after the end of an error frenzy, is to append to their transaction log, and they seem extremely separated with their internal structures etc so if anyone COULD have found a way to not use a single log to contend on, it would be them.

I really do apologize for caps but hasty use of BTRFS is a BAD IDEA still, please stick to EXT4 or XFS.

Comment

come back in a few years and let me know when Butter Face will be ready as it looks like shit to me and has way to many bugs and missing way to many things to be called ready i don't even know why they call it stable at all or is it stable for testing

Comment

BTRFS has a serious Achilles heel and... ironically its COW & snapshots...
Every time a snapshot is made, it?s b-tree changes, and when it changes, that forces the entire file system structure (b+tree) to be modified and duplicated on each file system snapshot.
So that creates an exponential degradation each and every time a snapshot is performed simply because its COW feature is working against it really badly.
So... the very benefit BTRFS has as its best feature its always defended for(snapshots) completely makes the file system into a ticking data-time-bomb until there?s an exponential metadata overload to the point of a grinding halt and system freeze, just because there are too many nodes created by the snapshots which cause that exponential b-tree node duplication.
This is a very serious reason to NOT USE BTRFS AS DEFAULT BECAUSE ALL BTRFS FILE SYSTEMS WILL NEED TO BE DESTROYED AND RECREATED IF/WHEN THIS PROBLEM IS EVER SOLVED.
Also, all the REAL databases like Postgres, Oracle, MSSQL and MySQL etc, have realized that the only true way to be consistent and able to not be insane after the end of an error frenzy, is to append to their transaction log, and they seem extremely separated with their internal structures etc so if anyone COULD have found a way to not use a single log to contend on, it would be them.

I really do apologize for caps but hasty use of BTRFS is a BAD IDEA still, please stick to EXT4 or XFS.

Valerie Aurora said, in the mentioned lwn article, that that is why, in the past, btrees and COW were thought to be ill wed to one another. That's why they aren't using btrees, but modified btrees (according to ohad rodeh's paper "B-trees, shadowing and clone") to avoid this problem.