Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Building new server, questions about RAID-1, UUID, btrfs, et
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3385

PostPosted: Mon Dec 23, 2013 6:08 pm    Post subject: Building new server, questions about RAID-1, UUID, btrfs, et Reply with quote

I'm in the process of building a new server. I don't have all of my hardware yet, most notably one of the new disks, but I need to get the bugger into service before then.

One of the things this new server will be doing is serving /home over nfsv4, and my current /home is 89% full. (That's part of the reason for the rush, that's a post-scrub number.) Currently /home is ext4 on raid-1, using mdadm. In the long run I'd like to be using btrfs, so I can use snapshots as a "Time Machine" type function. But today I'm still a bit skittish about btrfs, and was planning on ext4 on raid-1 again - just much more disk space.

I'm also moving my MythTV backend to this machine, and will be adding more non-RAID MythTV space to it.

My problem is that I'm going to be swapping disks in and out of this machine, between MythTV and /home. It's going to start with 1 drive for MythTV, 500G of a 2TB drive for one side of the /home RAID, and a spare 500G drive as the other side of the /home RAID. Early next year, when I get my second 2TB drive I plan to :
1 - Build a new RAID-1 using the new 2TB drive, with "missing" as the second drive.
2 - Copy the data over from the 500G "temporary" /home RAID.
3 - Take the old 2TB drive offline, running the old RAID with it missing.
4 - Reformat and add the old 2TB drive to the new RAID, and let it sync.
5 - Take the old RAID offline, and point /home to the new RAID.

In and around this time I'll be moving my MythTV collection from another machine, bringing the new machine up as my mythbackend, then adding the old mythtv drive to the new machine, to increase it's storage and bandwidth.

So it's clear that I'm going to be juggling drives in this new server, and specifying /dev/sdXX for any purposes is going to be problematic. At the moment I've got both fstab and grub.conf working with UUIDs, in anticipation.

I'm just not sure how to do the RAID work, considering drive letters will be changing, and for a while I'll have 2 RAIDS running at the same time, and if I use /dev/sdXX any pointers in /etc/mdadm.conf will certainly be wrong.

For other facts, the 500GB partition on the 2TB drive is currently typed as "fd". I don't know if I've got auto-assemble enabled in the kernel of not, but that can obviously be changed. I've been planning on using 1.2 metadata. The RAID drives are currently partitioned as MSDOS-type, but I suppose I could change them to GPT, if that's necessary. It appears that MSDOS doesn't have a partition-level UUID, and GPT does.

Any advice welcome, please.

EDIT

Or is my fear of btrfs unfounded - should I just use btrfs and it's built-in RAID, which should let me add and remove drives. From what I gather it also handles the partition issue more cleanly, and I could pair my current 2TB + 500GB, and as long as I don't go over 500GB I'm OK. But will btrfs also have issues with drive letters changing underneath it?
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
Kompi
Apprentice
Apprentice


Joined: 05 Oct 2002
Posts: 252
Location: Germany

PostPosted: Mon Dec 30, 2013 12:11 pm    Post subject: Reply with quote

mdadm should not have a problem with changing drive device names. An "mdadm --assemble --scan" will probe all block devices for RAID volumes and assemble them correctly by reading the metadata from the physical partitions. You do not need auto-detection enabled in the kernel for that. This should only be necessary if your root is on a raid and you do not use an initramfs. However, as far as I know that is not recommended.

I am using btrfs for quite some time now, even on production servers. The last problem I encountered was at lest 2 years ago, since then it has been quite stable. And it was probably even related to a hardware problem. However, as far as I know the RAID part is still considered somewhat experimental. For that reason, if you want to play safe, you can also create a btrfs on top of an MD RAID. But it is true, with the internel btrfs RAID stuff you do have some advantages. It should be able to detect and correct any errors when mirrors are out of sync, as it keeps checksums on a file level - while MD RAID cannot know which copy is the correct one if it encounters problems in a 2-way mirror. Also, you will not have long re-syncs in case of failures. Additionally, you should have a lot more flexibility resizing your array with btrfs. So, feature wise that would definitely be the way to go - just keep in mind, it may contain bugs.

As with mdadm, btrfs should be very much capable of detecting btrfs volumes on changing device node names. As I said, I have not used it much so far, but as I understand it, if you mount btrfs from one physical volume, it should be able to auto-detect other volumes automatically by scanning for the metadata on your partitions.

GPT or MSDOS partitions should not make a huge difference for any of this.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3385

PostPosted: Mon Dec 30, 2013 2:10 pm    Post subject: Reply with quote

I wound up building my initial RAID just the other day, and I decided to repartition the devices as GPT, so I could get /dev/disk/by-partuuid for them. I built the raid using that form of the disk, along with 1.2 metadata. So far it's all been good, especially as the one drive is eSATA, and the connectors are a little flakey. What's worse is that the eSATA drive naturally pops in at /dev/sda if it's there at boot, so it moves ALL of the drives around. Fortunately I'm mounting everything by UUID, so it all stays working.

Other than the mildly flakey connectors, I've had no problems so far. Currently the RAID is re-syncing the eSATA drive, and i'm also rsyncing some of my current RAID onto it, from my main server.

I decided to start off with ext4 instead of btrfs, if only because conversion is possible. I'll probably wait for btrfs until I assemble my permanent RAID.

Is there any sort of performance comparison between mdadm RAID1 and the btrfs built-in RAID1? The mdadm RAID1 is able to use both spindles and head positions for performance improvement on reads, though of course it writes like just one drive. Does btrfs do that, too?
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
Kompi
Apprentice
Apprentice


Joined: 05 Oct 2002
Posts: 252
Location: Germany

PostPosted: Mon Dec 30, 2013 2:30 pm    Post subject: Reply with quote

There are some benchmark results here, but they seem to be a bit old:
https://btrfs.wiki.kernel.org/index.php/Multi-device_Benchmarks
Maybe there is something in this list as well:
https://btrfs.wiki.kernel.org/index.php/Main_Page#Benchmarking

You may find more benchmarks on http://www.phoronix.com. However, a quick search did not show any results for btrfs RAID setups.

btrfs should be able to do the concurrent read from two mirrors at once as well. But I'm not sure at what stage the performance tuning of the current implementation is. Maybe there is some more info on that on https://btrfs.wiki.kernel.org.

Also, if you want to increase performance of a btrfs filesystem you should have a look at the mount options:
https://btrfs.wiki.kernel.org/index.php/Mount_options
I would always use the options "noatime", unless you really need access time stamps, as well as "space_cache". If you have compressable data I would also recommend using "compress=lzo". This saves space while at the same time increase I/O performance, as the CPU is generally faster in (de)compressing than the disk I/O is. This improved boot and program startup times for me when using on a root file system. Also very good for a portage tree. But of course only helpful if your data is not compressed tarballs, movies, audio files etc.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum