From ArchWiki
Revision as of 02:28, 7 March 2012 by AskApache (talk | contribs) (Copy the partition table)
Jump to: navigation, search

Alternate setups and filesystems

Just wanted to mention these directions worked great for me. It would be nice to have more examples for alternate setups and good ideas for filesystems, etc.. AskApache 15:07, 22 February 2012 (EST)

Hey AskApache, it's really rewarding to hear that this article was helpful. I spent a fair amount of time modifying and updating the old Installing with Software RAID or LVM article. Unfortunately, I was never able to spend enough time updating this article. Thankfully, 6arms1leg has made some excellent contributions, along with yourself.
Anyway, could you explain what alternate setups might apply? The filesystem question is an interesting one. I didn't realize there are alternatives to Linux raid auto. And that the Non-FS data allows you to format the array with any filesystem. After some quick searching, the Optimum RAID article on Linux Pro Magazine looks like a good place to start.
~ Filam 09:51, 23 February 2012 (EST)
Sure Filam, basically I would like more advanced and basic information about everthing! But specifically partioning and filesystems.
  • If you have 5 disks of different sizes, and the smallest disk is 500GB and the largest disk is 1.5TB, you can create a raid array on all 5 by creating a 500GB partition on each disk and use those partitions to create the array.
  • Some people using raid like to create a swap partition on each disk and then make a raid 0 array out of those for a fast swap (which is actually kind of redundant as swap already does raid 0 like striping when given multiple swaps with the same priority).
  • Back to the 5 disks, you could create a 100GB partition on each disk and create a raid 0 array out of that for a super fast /usr, /var, /lib directories which can be replaced in case of data loss. And then create 400GB partition on all 5 disks and create a raid 5 array on those partitions for a fast yet data-redundant /home/ directory.
  • You can create any filesystem on a raid array, but some are noticeably better than others. The same things apply here that are mentioned in the Maximizing Performance article.
  • Basically, XFS might be the best to use for a backup raid array containing large backup files, while reiserfs or ext4 might be the best for /home/.
  • When making an XFS filesystem on a raid array, XFS automagically recognizes it is a raid device and optimizes the XFS filesystem settings for you, however ext and reiserfs may need tweaked settings for optimization.
  • Filesystem settings correlate to the chuck-size and other mdadm options in the initial array creation as well, and should be factored in before creating the array.
  • More instructions on backing up partition tables and maybe even how to restore (good excercise to leave to reader)
  • Different ways to mount the devices in /etc/fstab
  • How to test speed
  • More instructions on customizing the mdadm.conf file
I'm working on this too but probably won't be editing anything again for awhile.. Thanks for this article!
--AskApache 13:00, 27 February 2012 (EST)
Thanks, but i don't really get your points.
What do you mean by filesystem?
A RAID array can be formatted with almost any filesystem that supports its size, while some of course are better suited than others. To the system the array is just a block device under /dev like any other.
If you just mean the fs-type tag in the partition table, the only suitable otions for RAID are "Non-FS data" and "Linux raid auto". But the fs-type tag you choose during partitioning is independant from the filesystem you format a disk/array with. The fs-tag only is important for system processes to recognize the correct filesystem (e.g. auto assembly of a RAID array during boot or using mount without the -t option). "Non-FS data" is the preferred method (see our RAID wiki page here, the paragraph after the note).
Sure, there is a lot to improve on that wiki page, but before someone makes the effort to write about the details, it would be nice to complete some of the basics. For example we have the most common RAID levels explained in the Introduction section but only one step-by-step guide for a level 5 array.
Also, I disagree with some of your edits in the following sections:
Regarding the combination of RAID and filesystem parameters, that fact is mentioned in this section. There also is a reminder to do the RAID-math, suitable at least for ext-filesystems.
Some things on your wishlist, I think belong in other wiki pages (esp. information about /etc/fstab and partitioning)
Don't take me wrong, I'm glad someone cares about this page.
6arms1leg 18:41, 5 March 2012 (EST)
It's great to hear from you, 6arms1leg, and thanks for the thorough explanation. If it wouldn't be much trouble would you mind moving each of your points about AskApache's edits into a separate section? Or, AskApache, if you come across this first and would like to respond, just copy the point you would like to respond to into another section. Thanks, ~ Filam 10:52, 4 March 2012 (EST)
Not too much trouble at all, but I'm not quite sure what you are picturing. As you can see, I edited my post and moved my points into different sections. To me, the way I rearranged it now, it doesn't improve readability nor provides it a better overview. Please feel free to re-edit my post the way you think it looks best. 6arms1leg 18:41, 5 March 2012 (EST)
Ah, it is probably more clear if I just edit it. The readability was fine, it was just difficult to respond to. ~ Filam 21:02, 5 March 2012 (EST)
Thanks for your effort. 6arms1leg 04:45, 6 March 2012 (EST)

Copy the partition table

Note: Moved from #Alternate setups and filesystems. ~ Filam 21:02, 5 March 2012 (EST)

I don't like or understand your edits on the Copy the partition table section (no offense). To me, your edits make the process more complicated. For example, why did you remove the command # sfdisk -d /dev/path_to_formatted_array_disk | sfdisk /dev/path_to_unformatted_array_disk and replaced it with one that first dumps a file which you then copy to the next disk? And why would you want to keep a backup of your partition table?

I also prefer the use of a pipe. ~ Filam 21:02, 5 March 2012 (EST)
Not sure why you don't like the edit, lol. The reason I replaced the sfdisk command using a pipe to one using a file is 2-fold:
  1. Depending on how your shell is setup or currently configured, using a pipe will not work correctly. This can be caused by a couple things such as the IFS variable and various shell options.
  2. By sending the output to a file you can easily replicate it in the future if your original partition table is corrupted.
-AskApache 21:28, 6 March 2012 (EST)

Prepare the device

Note: Moved from #Alternate setups and filesystems. ~ Filam 21:02, 5 March 2012 (EST)

Why do you think it is neccessary for the array to do a # dd if=/dev/zero of=/dev/disk-to-clean bs=4096 count=1 before creating it?

Removed information about BAARF and related stuff

Note: Moved from #Alternate setups and filesystems. ~ Filam 21:02, 5 March 2012 (EST)

I also disagree with you removing the BAARF stuff and the advice to use RAID-10 (not only for redundancy) instead. RAID-5 does have some serious performance issues, using a database on such an array can be a real pain.

There is a note in the RAID 5 definition that recommends using RAID 10. Can you link to the edit you're referring to? ~ Filam 21:02, 5 March 2012 (EST)
Yes, there is still a note, but it is very misleading as it only states redundancy as a reason. I like the old version better, which contained much more (important) information. It even had a warning banner. Both edits were made here (last two removed paragraphs in RAID 5 of the Introduction section: the warning banner + paragraph about BAARF).
6arms1leg 05:19, 6 March 2012 (EST)

Partition code for "Non-FS data"

Does anyone know what MBR hexadecimal code or GUID corresponds to the "Non-FS data" type in cfdisk? ~ Filam 13:43, 4 March 2012 (EST)

"Non-FS data" is defined in the msdos_systypes structure array within the GNU fdisk sys_types.h header file. The hexadecimal value is 0xda. ~ Filam 15:03, 4 March 2012 (EST)