Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
btrfs, RAID5 and performances
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2013-11-12
02:52 PM
2013-11-12
02:52 PM
btrfs, RAID5 and performances
Now that I have a RAID5 system running on a 104 box. I have the following comment/questions.
As far as I can tell, btrfs is not handling the RAID 5 process, but instead operates on top of a RAID5 MD device. This is not a great solution as MD based raid recovery is a long/slow process for large drives and the basic ARM chip inside a 104 seems to have problems performing the required XOR calculations quickly.
- When can we expect native btrfs RAID 5 support - once available (and stable) this will offers far better recovery for a disk failure.
- Any change that XRAID will support btrfs' RAID 10 option as currently it auto grows RAID 0 -> RAID 1 -> RAID 5 as you add disks.
As far as I can tell, btrfs is not handling the RAID 5 process, but instead operates on top of a RAID5 MD device. This is not a great solution as MD based raid recovery is a long/slow process for large drives and the basic ARM chip inside a 104 seems to have problems performing the required XOR calculations quickly.
- When can we expect native btrfs RAID 5 support - once available (and stable) this will offers far better recovery for a disk failure.
- Any change that XRAID will support btrfs' RAID 10 option as currently it auto grows RAID 0 -> RAID 1 -> RAID 5 as you add disks.
Message 1 of 5
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2013-11-20
02:19 AM
2013-11-20
02:19 AM
Re: btrfs, RAID5 and performances
+1 for me too.
I would like to be able to choose a physical volume model that uses btrfs natively *without* MD raid.
While I find FlexRAID to be reasonable, I have deployed my own systems that use btrfs on top of the physical volumes and find the flexibility of doing so useful.
I would like to be able to choose a physical volume model that uses btrfs natively *without* MD raid.
While I find FlexRAID to be reasonable, I have deployed my own systems that use btrfs on top of the physical volumes and find the flexibility of doing so useful.
Message 2 of 5
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2013-11-24
08:09 PM
2013-11-24
08:09 PM
Re: btrfs, RAID5 and performances
This may take a lot of redesign, as the current infrastructure seems to depend massively on MD, especially for expansion.
Similar to the age old request for iSCSI LUNs to be on raw devices, not a large flat file on top of the filesystem (much overhead).
Similar to the age old request for iSCSI LUNs to be on raw devices, not a large flat file on top of the filesystem (much overhead).
Message 3 of 5
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2013-11-26
06:29 PM
2013-11-26
06:29 PM
Re: btrfs, RAID5 and performances
The only reason why your design relies so heavily on MD is because you use it to manage the RAID configuration on top of it.
This is fine if you only want to look at the storage as a RAID pool first, and a btrfs store second.
The end result is that you only ever present a single volume to btrfs, negating all the useful multiple volume stuff that btrfs provides.
The btrfs only model just requires presenting the physical volumes to brtfs. No MD, no software RAID. Any argument that starts with "We need MD to be able to manage..." totally misses the point.
If I want storage expansion then I can manage that through btrfs. What I can't do with this model is the vertical expansion of the existing physical volumes.
As long as this is documented and the user is aware it would not be an issue.
I can already manually configure my 104 to provide a physical volume btrfs store in no time flat. I could possibly provision all my btrfs subvolumes manually as well, but it would be a chore.
You already have all the management code to handle the btrfs store. Once a btrfs store is created the management is identical.
All you need is a management layer to create the btrfs store without MD and RAID underneath it. It would just be an extra configuration layer: X-RAID, FlexRAID, and JBOD btrfs.
Just my 10c worth.
This is fine if you only want to look at the storage as a RAID pool first, and a btrfs store second.
The end result is that you only ever present a single volume to btrfs, negating all the useful multiple volume stuff that btrfs provides.
The btrfs only model just requires presenting the physical volumes to brtfs. No MD, no software RAID. Any argument that starts with "We need MD to be able to manage..." totally misses the point.
If I want storage expansion then I can manage that through btrfs. What I can't do with this model is the vertical expansion of the existing physical volumes.
As long as this is documented and the user is aware it would not be an issue.
I can already manually configure my 104 to provide a physical volume btrfs store in no time flat. I could possibly provision all my btrfs subvolumes manually as well, but it would be a chore.
You already have all the management code to handle the btrfs store. Once a btrfs store is created the management is identical.
All you need is a management layer to create the btrfs store without MD and RAID underneath it. It would just be an extra configuration layer: X-RAID, FlexRAID, and JBOD btrfs.
Just my 10c worth.
Message 4 of 5
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2013-11-26
06:47 PM
2013-11-26
06:47 PM
Re: btrfs, RAID5 and performances
Agreed. But the foundation of ReadyNAS is using MD back to 2004. They won't be changing it overnight.
The ReadyDATA business line was built up in 2012 based on illumos, so it doesn't have this hindering. But that probably won't migrate across to the consumer stuff.
The ReadyDATA business line was built up in 2012 based on illumos, so it doesn't have this hindering. But that probably won't migrate across to the consumer stuff.
Message 5 of 5