Live data from Hacker News

Btrfs Allocator Hints

lwn.net

61–62 of 62 posts

Re: Btrfs Allocator Hints

#61
post #45

Earlier quoted context omitted.

Sure, I can believe this. Does not change the fact that some people encounter compete data loss with it. Sadly, there are people (and distributions) which recommend btrfs for general-purpose root filesystem, even for the cases where reliability matters much more than performance. I think that part is a mistake,

I would recommend btrfs as general purpose root filesystem. Any FS will have people encountering data loss. I can believe btrfs has N times higher chance of data loss because its packed with features and need to maintain various complicated indexes which are easier to corrupt, but I also believe that one should be ready that his disk will fail any minute regardless of FS, and do backup/replication accordingly.

While I did that and lost near to nothing, I still think that this should not be the default approach of developing a filesystem... it should be ready to restore as much as possible in case of hardware failure or data corruption.

Re: Btrfs Allocator Hints

#62

Earlier quoted context omitted.

I would recommend btrfs as general purpose root filesystem. Any FS will have people encountering data loss. I can believe btrfs has N times higher chance of data loss because its packed with features and need to maintain various complicated indexes which are easier to corrupt, but I also believe that one should be ready that his disk will fail any minute regardless of FS, and do backup/replication accordingly.

While I did that and lost near to nothing, I still think that this should not be the default approach of developing a filesystem... it should be ready to restore as much as possible in case of hardware failure or data corruption.

there is standard approach: you setup raid, and FS will restore as much as possible and likely everything. Adding extra complexity to cover some edge cases maybe is too overkill.
Post reply on HN