On 9/16/13 10:05 AM, Sebastian wrote:
On 09/16/2013 03:48 PM, Thorsten Kukuk wrote:
On Mon, Sep 16, Sebastian wrote:
i've been using btrfs for over a year now on both root and home with raid1 and compression (whereas /home is on an encrypted lvm), and had several unmountable partitions.
btrfs raid functionality? Hardware raid? mdraid? Sorry, btrfs with raid1 is a little bit to vague. If you mean brtrfs raid functionality: everybody knows that this is unstable and you should not use it, that's why Jeff Mahoney proposed to enable it only with a special command line option.
btrfs raid0/1 is as stable as the rest of btrfs, widely used and well tested (read #btrfs on freenode). btrfs with raid5/6 is unstable and in testing.
I'm not sure what response you expect here. You're claiming it's stable. I've claimed in many locations and fairly vocally that raid (of any level) and compression are not yet. If you don't want to trust my team's determination on what's mature and what's not, that's your right. But then don't go and claim the entire file system is unstable and will lose your data when it turns out we know what we're talking about. That doesn't mean we're not going to try to fix your file system, but it does mean it's outside of the case we've established as stable.
moreover, for anything that uses a database (better: has many writes in small portions) like sqlite,
For every database: journaling file systems are always the performance dead for them. There are reasons why people suggest to disable journaling always, even with ext3 and ext4, if you use databases and if you want performance.
the reason here for btrfs is COW. with more and more and more updates it^ll become so fragmented alone reading will take ages.
It's more complicated than the cases either of you are making. In the ext* case, the cost isn't the journaling directly, it's the fsync that (at least with ext3, it's better in ext4) forces a complete journal sync. The database writes themselves don't go through the journal, but because ext* has a data=ordered implementation that basically puts all writes on the ordered list, the writes have to complete before the journal sync completes. Moving to data=writeback means that the writes don't have to complete before the journal commit. This is typically safe with databases since they tend to preallocate as well as use fsync pretty regularly. The btrfs case does involve CoW but fragmentation is pretty unrelated in the write path. We still will end up creating ordered writes and waiting for them, but we'll need to wait for the allocation to complete and the accompanying metadata tree updates that happen as well. Reads may be impacted by fragmentation but btrfs also has online defrag.
plus if someone from suse decides to add a "allow_unsupported" switch within initrd, your system becomes unbootable for no reason whatsoever....
That's sound more like you are using the unstable features even kernel developers warns for.
btrfs core is stable, but there are a lot of btrfs features, which are far away from being stable.
the question why that would render MY system unbootable, whereas btrfs would mount without problem, is still unanswered.
The allow_unsupported patch hasn't been added to the openSUSE kernel yet, so that's not what's rendering your system unbootable. -Jeff -- Jeff Mahoney SUSE Labs