My primary OpenELEC system is a media player, downloader and file server serving media to other OpenELEC clients around the house. I have multiple drives for media storage.
The problem is that managing content and downloads on separate drives is cumbersome. For example, you can set a download directory on one drive for SABnzbd, but when the drive is full you have to change it to a different drive. If you delete content on the first drive you can't make use of the space until you move files around manually. It soon becomes messy.
btrfs
OpenELEC supports drives formatted in btrfs [info] which supports JBOD drive pooling. You can create a storage pool in a Linux Live environment with btrfs-tools then use it in OpenELEC. Performance is very good because the filesystem is supported at the kernel level. However, if one drive fails you lose all the data on all the drives, and I'm not sure if you can add additional drives after the initial JBOD array is set up. btrfs is in heavy development and could be unstable so I would be wary of storing terabytes of data with it.
mhddfs
mhddfs [info] is a userspace program which creates a FUSE filesystem that pools together drives/partitions and presents them as a single virtual filesystem. It is much more flexible than btrfs JBOD - open the link for a good description. You can use drives with existing data on them, and if a drive fails you don't lose the data on the other drives. You can even add just a part of a drive to a pool, since you can choose any mount point.
If you have a 'movies' directory on each drive, with different movies in each, then it will merge them together into one virtual 'movies' directory which contains all of the movies from all drives.
There is a performance hit when using a FUSE filesystem, but it hasn't affected me much. I'm able to download to the virtual filesystem while playing media and can stream media to another device at the same time without problem. YMMV.
Fortunately OpenELEC already includes the necessary FUSE libraries for mhddfs. So all you need is the binary, and since it runs in userspace you can execute it from any writable location.
aufs
Technically the best solution [info]. Provides the flexibility of mhddfs with the performance benefits of running at the kernel level. Unfortunately this requires a kernel patch (and therefore a custom OpenELEC build). I prefer to use official builds, and the performance of mhddfs is adequate for my needs, so I will stay with mhddfs for now. Maybe I'll do a custom build one day. Shouldn't need to change anything on the existing drives when going from mhddfs to aufs.
How to install mhddfs
1) Download this zip file:
mhddfs_openelec.zip (Size: 31.3 KB / Downloads: 1)
mhddfs_openelec.zip[/attachment]
2) Copy the mhddfs binary for your platform to /storage/.config
3) Make the binary executable:
cd /storage/.config
chmod +x mhddfs
4) Copy the autostart.sh to /storage/.config. If you already have an autostart.sh, insert the following:
4) The sleep value is the number of seconds the system waits before running mhddfs on startup. Your drives must be mounted before running mhddfs, you may have to change this value based on how long your drives take to mount - e.g. external USB drives might take longer to mount.
5) Substitute the following parts with the names of your drive mount points. You can add more drives here, just separate them with a comma.
/var/media/[drive1]
/var/media/[drive2]
6) /storage/pool is the mount point I use for the virtual storage pool. Create an empty directory in /storage called /pool. You can name it anything you like, just be aware that if you use an existing directory then the original contents of that directory will be hidden while mhddfs is running.
7) The option '-o nonempty' is a FUSE option which will mount the virtual filesystem even if the specified mount point contains data. I recommend using this setting, as other processes may create data in that directory before mhddfs starts which would cause the mount to fail.
8) Test by manually running it:
cd /storage/.config
./mhddfs /var/media/[drive1],/var/media/[drive2] /storage/pool -o nonempty
You should see some information about the mount. Type df - h to confirm that the pool has been created.
9) Reboot for mhddfs to run at next boot.
My set up (all internal SATA)
Notes
1) All my drives are formatted in EXT4 for best compatibility and performance. Other formats should work though. Note that using a format that OpenELEC accesses via FUSE, such as exFAT or NTFS, means that you will be doubling the usage of FUSE, which can reduce performance and increase CPU usage.
2) If one of your media storage drives is also your boot drive, you can still create a storage pool. Example, if the boot drive has mount points at /flash and /storage and your media is stored at /storage/media, and your second drive is at /var/media/drive2 with your media at the root of that drive, then your command should be something like this:
3) I don't have my hard drives going to standby after inactivity, as I was having problems with it, but theoretically it should work with mhddfs pooling.
4) For simplicity, I access all my media files through /storage/pool. But you could also access the files directly from the drives, e.g at /var/media/WD3TB. You could do this if you wanted to squeeze some extra performance when copying files.
5) I set XBMC to use one source for each media type e.g. /storage/pool/movies, /storage/pool/tvshows, /storage/pool/music. My SABnzbd download directory is /storage/pool/downloads. XBMC, SABnzbd, etc don't need to know which physical drive the files are on. Let mhddfs handle the management of free space etc.
6) On recent versions of Kodi, you may encounter problems with library scanning a folder on the drive pool. To fix, use the following setting in advancedsettings.xml (Source)
The problem is that managing content and downloads on separate drives is cumbersome. For example, you can set a download directory on one drive for SABnzbd, but when the drive is full you have to change it to a different drive. If you delete content on the first drive you can't make use of the space until you move files around manually. It soon becomes messy.
btrfs
OpenELEC supports drives formatted in btrfs [info] which supports JBOD drive pooling. You can create a storage pool in a Linux Live environment with btrfs-tools then use it in OpenELEC. Performance is very good because the filesystem is supported at the kernel level. However, if one drive fails you lose all the data on all the drives, and I'm not sure if you can add additional drives after the initial JBOD array is set up. btrfs is in heavy development and could be unstable so I would be wary of storing terabytes of data with it.
mhddfs
mhddfs [info] is a userspace program which creates a FUSE filesystem that pools together drives/partitions and presents them as a single virtual filesystem. It is much more flexible than btrfs JBOD - open the link for a good description. You can use drives with existing data on them, and if a drive fails you don't lose the data on the other drives. You can even add just a part of a drive to a pool, since you can choose any mount point.
If you have a 'movies' directory on each drive, with different movies in each, then it will merge them together into one virtual 'movies' directory which contains all of the movies from all drives.
There is a performance hit when using a FUSE filesystem, but it hasn't affected me much. I'm able to download to the virtual filesystem while playing media and can stream media to another device at the same time without problem. YMMV.
Fortunately OpenELEC already includes the necessary FUSE libraries for mhddfs. So all you need is the binary, and since it runs in userspace you can execute it from any writable location.
aufs
Technically the best solution [info]. Provides the flexibility of mhddfs with the performance benefits of running at the kernel level. Unfortunately this requires a kernel patch (and therefore a custom OpenELEC build). I prefer to use official builds, and the performance of mhddfs is adequate for my needs, so I will stay with mhddfs for now. Maybe I'll do a custom build one day. Shouldn't need to change anything on the existing drives when going from mhddfs to aufs.
How to install mhddfs
1) Download this zip file:
mhddfs_openelec.zip (Size: 31.3 KB / Downloads: 1)
mhddfs_openelec.zip[/attachment]2) Copy the mhddfs binary for your platform to /storage/.config
3) Make the binary executable:
cd /storage/.config
chmod +x mhddfs
4) Copy the autostart.sh to /storage/.config. If you already have an autostart.sh, insert the following:
Code:
#! /bin/sh
(sleep 3;
/storage/.config/mhddfs /var/media/[drive1],/var/media/[drive2] /storage/pool -o nonempty;
)&4) The sleep value is the number of seconds the system waits before running mhddfs on startup. Your drives must be mounted before running mhddfs, you may have to change this value based on how long your drives take to mount - e.g. external USB drives might take longer to mount.
5) Substitute the following parts with the names of your drive mount points. You can add more drives here, just separate them with a comma.
/var/media/[drive1]
/var/media/[drive2]
6) /storage/pool is the mount point I use for the virtual storage pool. Create an empty directory in /storage called /pool. You can name it anything you like, just be aware that if you use an existing directory then the original contents of that directory will be hidden while mhddfs is running.
7) The option '-o nonempty' is a FUSE option which will mount the virtual filesystem even if the specified mount point contains data. I recommend using this setting, as other processes may create data in that directory before mhddfs starts which would cause the mount to fail.
8) Test by manually running it:
cd /storage/.config
./mhddfs /var/media/[drive1],/var/media/[drive2] /storage/pool -o nonempty
You should see some information about the mount. Type df - h to confirm that the pool has been created.
9) Reboot for mhddfs to run at next boot.
My set up (all internal SATA)
Code:
OpenELEC1:~ # df -h
Filesystem Size Used Available Use% Mounted on
devtmpfs 1.9G 164.6M 1.7G 8% /dev
/dev/sda1 230.4M 172.1M 54.3M 76% /flash
/dev/sda2 18.0G 14.2G 3.8G 79% /storage
/dev/loop0 164.6M 164.6M 0 100% /
tmpfs 782.4M 4.0K 782.4M 0% /dev/shm
tmpfs 10.0M 720.0K 9.3M 7% /var
/dev/sdb2 2.7T 2.7T 3.5G 100% /var/media/WD3TB
/dev/sdc1 3.6T 3.4T 1.3G 100% /var/media/HGST4TB
/dev/sdd1 3.6T 3.4T 3.8G 100% /var/media/HGST4TB2
/dev/sde1 3.6T 3.4T 2.6G 100% /var/media/WD4TB
/dev/sdf1 4.5T 1.1T 3.2T 26% /var/media/WD5TB
/var/media/WD3TB;/var/media/HGST4TB;/var/media/HGST4TB2;/var/media/WD4TB;/var/media/WD5TB
17.9T 14.0T 3.2T 81% /storage/poolNotes
1) All my drives are formatted in EXT4 for best compatibility and performance. Other formats should work though. Note that using a format that OpenELEC accesses via FUSE, such as exFAT or NTFS, means that you will be doubling the usage of FUSE, which can reduce performance and increase CPU usage.
2) If one of your media storage drives is also your boot drive, you can still create a storage pool. Example, if the boot drive has mount points at /flash and /storage and your media is stored at /storage/media, and your second drive is at /var/media/drive2 with your media at the root of that drive, then your command should be something like this:
Code:
/storage/.config/mhddfs /storage/media,/var/media/drive2 /storage/pool -o nonempty3) I don't have my hard drives going to standby after inactivity, as I was having problems with it, but theoretically it should work with mhddfs pooling.
4) For simplicity, I access all my media files through /storage/pool. But you could also access the files directly from the drives, e.g at /var/media/WD3TB. You could do this if you wanted to squeeze some extra performance when copying files.
5) I set XBMC to use one source for each media type e.g. /storage/pool/movies, /storage/pool/tvshows, /storage/pool/music. My SABnzbd download directory is /storage/pool/downloads. XBMC, SABnzbd, etc don't need to know which physical drive the files are on. Let mhddfs handle the management of free space etc.
6) On recent versions of Kodi, you may encounter problems with library scanning a folder on the drive pool. To fix, use the following setting in advancedsettings.xml (Source)
Code:
<videolibrary>
<usefasthash>false</usefasthash>
</videolibrary>