Btrfs ate my netbook today. Unexpected power loss, when it came back it panicked on boot mounting the filesystem. Impossible to get a backtrace since most of it flies off the top of the screen, and AFAIK, btrfsck is a dummy command that doesn't actually fix anything. Back to ext4 for me then.

I guess I deserved the data loss for being naïve enough to use Oracle software in the first place _________________*.ebuild // /etc/service/*

btrfs remains under heavy development and is not yet intended for use where data loss is a problem or inconvenience. Using it at this point seems to be acceptance of such issues.

pjp wrote:

Anyway, as for trying ZFS, I've used ~arch way back when ('03 - '04) and had problems. I've decided to never do that again, so I only use stable. I'm also not interested in maintaining random overlays separately from portage (I find it to be a nuisance), and even less interested in maintaining custom ebuilds, especially of the critical variety. None of those scenarios are why I started using Gentoo, or continue using it.

Those two statements are contradictory. BTRFS is unstable at this time with no way to recover but you advocate it. ZFS is super stable but you don't want to use it just because its not in portage. Tells me you have a mental bias! But, to each their own!

As for what I have done, I've considered testing btrfs with data I don't care if I lose. I have installed btrfs in a virtual box, just to see how to interact with it (ZFS' cli is better IMO). In doing so, btrfs seems easier to implement currently than ZFS (without supported ebuilds, and purely from a package management point of view). If a supported ZFS ebuild comes along, I'd try it in a vm as well.

I'm glad you like ZFS. It seems appropriate for your situation and your tolerance for data loss._________________You're jumping to conclusions, so I can't keep up with you. Go on without me, I'll just slow you down.

i just had a situation where a btrfs partition wouldnt mount. solution is to mount the partition with 2.6.38 kernel one time, for example systemrescuecd 2.1.1, so it could repair the log. waiting for pf-sources-3.1 ..

i just had a situation where a btrfs partition wouldnt mount. solution is to mount the partition with 2.6.38 kernel one time, for example systemrescuecd 2.1.1, so it could repair the log. waiting for pf-sources-3.1 ..

O.o

had the same in the past & the only solution so far was to reformat, discard the data and backup again on that drive

Ant P.'s zeroing of the log also might work but could lead to data inconsistencies - hm, not a state to really rely on that filesystem solely

There's nothing wrong with throwing away corrupt incomplete data after a crash, xfs does it by default and you just lose the last 15 seconds of data or so. The main difference is that does it automatically, instead of kernel panicking, forcing you hunt across google for an hour and then manually compile a non-default tool from a livecd to fix it..._________________*.ebuild // /etc/service/*

There's nothing wrong with throwing away corrupt incomplete data after a crash, xfs does it by default and you just lose the last 15 seconds of data or so. The main difference is that does it automatically, instead of kernel panicking, forcing you hunt across google for an hour and then manually compile a non-default tool from a livecd to fix it...

That's just plain wrong! Is that your definition of enterprise-ready filesystem?

No, that's SGI's definition of an enterprise-ready filesystem. This has been its default behaviour for years. If you don't like it then RTFM and learn how to change the default.

devsk wrote:

Do you have any idea how many transactions can be processed in 15 seconds?

Simba7 wrote:

Let me make sure I *NEVER* hire you as a network or system administrator.

If you're even thinking of running mission-critical systems that can't tolerate 15 seconds of downtime on a standard Linux filesystem without redundancy and expecting not to lose data then I want to stay as far away from whatever company you work for as possible _________________*.ebuild // /etc/service/*

Btrfs ate my netbook today. Unexpected power loss, when it came back it panicked on boot mounting the filesystem. Impossible to get a backtrace since most of it flies off the top of the screen, and AFAIK, btrfsck is a dummy command that doesn't actually fix anything. Back to ext4 for me then.

I guess I deserved the data loss for being naïve enough to use Oracle software in the first place

Yeah, that huge commit seems promising for many fixes... although his last comment on btrfs "eating his data" with no possibility/time for fixes before pulling his request is not that appealing. I'd look at you guys--who are using btrfs--with a little distance with your "eaten data" funny stories before making any move to btrfs.

But hey, again, that pull request is impressive! and it's normally trouble free on top of 3.1.

after about 3 months of using btrfs on rootfs i gave up and switched back to ext4.

The systems is often unresponive and I even got serious slowdowns (cant really move mousepointer) when doing "emerge --sync", not to mention rsync...
Sometimes there are very long write-operations and I can't even tell why.

with ext4... all that stuff is gone, so it's definitely not just imagination.

I wanted to try btrfs with lzo compression for /usr/portage, hoping for the compression to speed things up.
Its partition size is only 512MiB. Unfortunately, the data does not even fit with btrfs. What a showstopper!

I wanted to try btrfs with lzo compression for /usr/portage, hoping for the compression to speed things up.
Its partition size is only 512MiB. Unfortunately, the data does not even fit with btrfs. What a showstopper!

It's a pity ext4 can't do compression. However, both its stability and configurability are great and I had no problems so far.

You need to enable the "-M" option when creating a small partition with btrfs. Otherwise it will use a lot of space for metadata. Regarding compressing /usr/portage you should probably use something like squashfs.

I wanted to try btrfs with lzo compression for /usr/portage, hoping for the compression to speed things up.
Its partition size is only 512MiB. Unfortunately, the data does not even fit with btrfs. What a showstopper!

It's a pity ext4 can't do compression. However, both its stability and configurability are great and I had no problems so far.

You need to enable the "-M" option when creating a small partition with btrfs. Otherwise it will use a lot of space for metadata. Regarding compressing /usr/portage you should probably use something like squashfs.