rt/snapraid
1
0
Fork 0
mirror of https://github.com/amadvance/snapraid.git synced 2026-10-26 19:01:57 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

Saving Page, Mid edit

Kayot 2015-08-25 23:25:05 -04:00
parent 56f1834323
commit c900ecb3cc
1 changed files with 34 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

34
pooling.md Normal file

@ -0,0 +1,34 @@
# Pooling Drives
* [Linux Solutions](pooling#Linux)
* [Windows Solutions](pooling#Windows)
## Linux
There are two main ways to pool drives in Linux that are favorable to using SnapRAID. The first is AUFS (Another Unified File System) and the second and probably better choice is mhddfs (Multi Hard Disk Device File System). Both are FUSE (Filesystem in Userspace) which typically means slower. However, as computers get faster and faster, the limitations with FUSE have gone away. The idea is that the file system interacts with the users pace layer, then the hardware layer and then from the hardware into the user space layer, adding a step both ways on each operation causing a massive slow down. Again, on decent hardware such as a Xeon E3-1220V3 with 8+ GB of ECC ram, this isn't going to bottleneck the process. Now if you are using this on a Raspery Pi, then you've made a poor choice in your NAS (Network Attached System).
MHDDFS - This used to be the poorer choice due to not being compiled into the kernel. However it became the better choice when AUFS was removed from the kernel. MHDDFS is very simple. Unlike AUFS which has file allocation abilities such as round robin, and most free space, MHDDFS only uses most free space. Meaning that files will be placed onto the drive with the most free space. This typically works well for Snapraid as it keeps the parity file about even with the drives. Meaning a full drive doesn't cause the parity files to become too big for their own drive.
To setup mhddfs, you must first download it.
`sudo apt-get isntall mhddfs`
Then mount the drives you want to pool to mount points. This works well since snapRaid can use the same mount points for making the parity files. We're going to assume that sda, sdb, and sdc are three drives in the computer.
`sudo mkdir A00,A01,A02,pool`
`sudo mount /dev/sda1 A00`
`sudo mount /dev/sdb1 A01`
`sudo mount /dev/sdc1 A02`
`mhddfs mhddfs A00,A01,A02 Pool -o allow_other`
That is a mhddfs pool in the most basic of the sense. The directory pool with have the contents of the three drives merged in its mount point. If the same file exists on two or more drives, the newest one is the one you will see. Deleting that file will delete both files. A simple pool.
AUFS - This used to be the better solution, however as of Linux Kernel 3.6, this is no longer compiled into the kernel turning it into a FUSE based system. AUFS has a lacking issue where it creates whiteout files when it can't lock a file for deletion. For some reason or another, these files never get deleted. Compounding this problem is that a poorly formed whiteout file can make a drive look empty but still use all the space as all the files are still there, only hidden by AUFS. As such, the following examples are just that, examples and should not be used on kernels at or above 3.6.
`sudo mkdir A00,A01,A02,pool`
`sudo mount /dev/sda1 A00`
`sudo mount /dev/sdb1 A01`
`sudo mount /dev/sdc1 A02`
`mount -t aufs -o br=A00=rw:A01=rw:A02=rw -o create=mfs none pool`
AUFS gives you a little more control, such as Read Write and Read Only permissions. However, the whiteout files are a serious hinderence that will eventually creep up. It is advisable to stick with MHDDFS.
## Windows