TR Forums

So I've got a server running Arch Linux at home that I use as a file/media server (plus any other fun stuff). Parts of it are kind of ugly because sometimes I'm in a results-oriented project mood rather than a process-oriented mood. Currently I have two physical drives: one for the system and one for the home directories. Both of these are ext4 file systems. My plan this weekend is to end up with an ext4 system drive and a 1TB btrfs raid1 storage drive that I'll use as my network share.

Does anyone have any experience trying this sort of thing? I'd love to hear it.

Btrfs is still considered somewhat experimental...

alloyD wrote:

Currently I have two physical drives: one for the system and one for the home directories.

OK, two... two harddrives. Ah ah ah ah ah...

alloyD wrote:

My plan this weekend is to end up with an ext4 system drive and a 1TB btrfs raid1 storage drive that I'll use as my network share.

That would require 1 system drive + another 2 drives [minimum] for the RAID 1 that makes... Three.. three harddrives. Ah ah ah ah ah.
Yeah... the BTRFS physical drive molecular clone function hasn't been commited to master yet.

Assuming you actually have the third drive, you can try out BTRFS but don't expect it to be miraculously better or different than an ext4 raid. Most of what makes BTRFS "better" than ext4 only really begins to manifest when you deal with very large volumes spanning very large numbers of physical drives. I will say that the COW snapshotting features are useful no matter how big your storage array, but you will have to take time to learn how to use them.

just brew it! wrote:

Btrfs is still considered somewhat experimental...

He's running his server on Arch.

bthylafh wrote:

just brew it! wrote:

Btrfs is still considered somewhat experimental...

He's running his server on Arch.

Ahh, good point.

just brew it! wrote:

bthylafh wrote:

just brew it! wrote:

Btrfs is still considered somewhat experimental...

He's running his server on Arch.

Ahh, good point.

Running an Arch server is much like war: Seemingly endless stretches of mind numbing boredom punctuated by brief moments of sheer terror when you realize that 6 months of cumulative updates have found a way to prevent the machine from rebooting.

I'm experimenting with (read using, but not trusting) a raid 5 btrfs setup with 4 3tb Toshiba drives. By and large, it works. The on the fly raid conversions between raid types is a really nice feature and the object level raid (mixing different raid types within an array on a per file or directory basis) will be a killer feature when it comes around. Where things seem to get sticky and messy is dealing with failed or failing drives. Supposedly (I haven't had to deal with this yet), btrfs doesn't yet have a mechanism for kicking a drive out of a live array without trying to rebalance off of the failing/failed drive first. You have to unmount, pull the bad drive, use the undocumented '-o degraded' mount option to remount the array, and then you can begin a rebalance to the lower capacity without the bad drive in the mix. Once that is done (depending on the amount of data a multi-day affair), you use the undocumented (notice a pattern here) 'btrfs device remove missing /my/array/mount/point' command. Then you can readd a new drive, and once again rebalance with a new drive.

TL, DR: Btrfs has cool features for raid, but is utterly unready for handling drive failures.

Debian stable, tested hardware, EXT4 for all filesystems.

When my server is offline, I can be certain there was a power outage.

I have VMs for when I'm feeling crazy, testing things, or just bored.

I have my laptop to explore Debian testing/unstable.

I have my server to serve things, without cease, day, night, slashdotting.

just brew it! wrote:

Btrfs is still considered somewhat experimental...

It's stable enough for SLES to use it as default. Considering that is an enterprise solution, it speaks volumes of it's maturity.

chuckula wrote:

Assuming you actually have the third drive, you can try out BTRFS but don't expect it to be miraculously better or different than an ext4 raid. Most of what makes BTRFS "better" than ext4 only really begins to manifest when you deal with very large volumes spanning very large numbers of physical drives. I will say that the COW snapshotting features are useful no matter how big your storage array, but you will have to take time to learn how to use them.

Yeah, I have a third drive I'll pull in to that. I do expect a learning curve for many of the features. The big thing for me is that btrfs can detect a corrupted file and correct automatically from the backup if my research is correct.

bthylafh wrote:

just brew it! wrote:

Btrfs is still considered somewhat experimental...

He's running his server on Arch.

Yeah, I'm not scared of experimental. The Arch project for me started out as a way to get a nice deep understanding of the inner working of a linux system. I've liked it so much that I never switched to anything else. I've also never encountered a problem in Arch that I haven't been able to fix... yet...

alloyD wrote:

Does anyone have any experience trying this sort of thing? I'd love to hear it.

It kind of depends on what kind of experience your looking for. Are you trying to do this with minimal downtime once the new disk is installed?

Flatland_Spider wrote:

It kind of depends on what kind of experience your looking for. Are you trying to do this with minimal downtime once the new disk is installed?

Preferably, but it's not my primary concern. I'm interested in playing around with the features and seeing how stable it really is for my applications.

Deanjo wrote:

just brew it! wrote:

Btrfs is still considered somewhat experimental...

It's stable enough for SLES to use it as default. Considering that is an enterprise solution, it speaks volumes of it's maturity.

I imagine stability is still dependent on which features you choose to use though; it is still very much a "work in progress". Furthermore, AFAICT it is not the default in SLES yet, only in OpenSUSE. (And SLES is to OpenSUSE as RHEL is to Fedora... "community" distributions are often used as test beds for new and/or experimental features.)

just brew it! wrote:

Deanjo wrote:

just brew it! wrote:

Btrfs is still considered somewhat experimental...

It's stable enough for SLES to use it as default. Considering that is an enterprise solution, it speaks volumes of it's maturity.

I imagine stability is still dependent on which features you choose to use though; it is still very much a "work in progress". Furthermore, AFAICT it is not the default in SLES yet, only in OpenSUSE. (And SLES is to OpenSUSE as RHEL is to Fedora... "community" distributions are often used as test beds for new and/or experimental features.)

According to SUSE, it's ready for production and has been supported since SLES 11 SP2.

http://www.linux.com/news/enterprise/sy ... dy-to-rock
http://events.linuxfoundation.org/sites ... _btrfs.pdf

Pretty much every filesystem out there is a "work in progress". Ext, XFS, OCFS2 even ReiserFS are still having features added to them and under development. Facebook started rolling out BTRFS deployments in April.

Deanjo wrote:

just brew it! wrote:

Deanjo wrote:

It's stable enough for SLES to use it as default. Considering that is an enterprise solution, it speaks volumes of it's maturity.

I imagine stability is still dependent on which features you choose to use though; it is still very much a "work in progress". Furthermore, AFAICT it is not the default in SLES yet, only in OpenSUSE. (And SLES is to OpenSUSE as RHEL is to Fedora... "community" distributions are often used as test beds for new and/or experimental features.)

According to SUSE, it's ready for production and has been supported since SLES 11 SP2.

http://www.linux.com/news/enterprise/sy ... dy-to-rock
http://events.linuxfoundation.org/sites ... _btrfs.pdf

Pretty much every filesystem out there is a "work in progress". Ext, XFS, OCFS2 even ReiserFS are still having features added to them and under development. Facebook started rolling out BTRFS deployments in April.

"Supported" is not the same as "default" though. Furthermore, the guy who invented it works for Facebook, so they're in a bit of a unique position.

just brew it! wrote:

"Supported" is not the same as "default" though. Furthermore, the guy who invented it works for Facebook, so they're in a bit of a unique position.

The latest betas of SLES 12 do indeed have it as default (and btw, SLES 12 is scheduled to be released before openSUSE 13.2 which will then have BTRFS as default).

In case anyone is interested, I did recently implement this. My current setup is like this:



sdb and sdc are part of a btrfs raid1 setup. It's working quite well and I'm using it mostly for archival and file server purposes.