coppit Posted January 9, 2011 Share Posted January 9, 2011 Let's say I have a layout like this: //disk1/Movies //disk2/TV Shows and a read/write user share that hides the details of which directories are on which disk, like this: //Share/Movies //Share/TV Shows When I write new files into Movies or TV Shows, I want unraid to put them first on disk1 or disk2, where those directories already exist. Only when a disk is full do I want it to create a new directory on a different disk. And only when that new directory is full should it create a similar directory on a third disk. This kind of allocation method helps minimize spin up of lots of disks if I'm browsing movies and not TV shows. I don't think I can do this with any of the allocation methods we have now, can I? Link to comment
lionelhutz Posted January 9, 2011 Share Posted January 9, 2011 The allocation method fill-up will fill a drive before moving to the next one. You must set a minimum free space which is larger than the largest file you will copy. I'd recommend going 2x as large to be safe. The free space setting is in kb. For a 40gig max file size set 80gig free. Then the free space setting would be 80000000. Take the number of meg of min free space you want and add 3 zero's. Take the number of gig of min free space you want and add 6 zero's. Peter Link to comment
Bags Posted January 9, 2011 Share Posted January 9, 2011 Is this done on the disk level or at the user share level? This sounds like what I would like to do. Link to comment
Stokkes Posted January 9, 2011 Share Posted January 9, 2011 Allocation methods only apply to user shares. Obviously if you're talking about disk shares, you're copying directly to the disk, so it's not doing any allocation. Link to comment
coppit Posted January 10, 2011 Author Share Posted January 10, 2011 Thanks Peter. I'll try it. Do you happen to know if the bug was fixed that caused writing to a user share to be significantly slower than writing to a disk directly? Link to comment
limetech Posted January 10, 2011 Share Posted January 10, 2011 Let's say I have a layout like this: //disk1/Movies //disk2/TV Shows and a read/write user share that hides the details of which directories are on which disk, like this: //Share/Movies //Share/TV Shows When I write new files into Movies or TV Shows, I want unraid to put them first on disk1 or disk2, where those directories already exist. Only when a disk is full do I want it to create a new directory on a different disk. And only when that new directory is full should it create a similar directory on a third disk. This kind of allocation method helps minimize spin up of lots of disks if I'm browsing movies and not TV shows. I don't think I can do this with any of the allocation methods we have now, can I? You can do this by setting 'split level' to 0 (i.e., put a zero there, not blank). This tells user share file system to always create any object on the same disk as that objects parent directory exists on. If the parent directory exists on multiple disks, then unRaid will choose which disk to use according to the share allocation method. So in your case, suppose you have this: disk1/Share/Movies disk2/Share/Movies disk3/Share/TV disk4/Share/TV If you now create "Share/Movies/Godfather", unRaid will use either disk1 or disk2 according to allocation method. If you set alloc. method to "fill up", then it choose lowest numbered disk until it's full, then next lowest etc. Now say you add disk5. Nothing will be put on there for Share user share until you explicitly define the parent directories. So say you want Movies to expand into disk5, you would create: disk5/Share/Movies Now the set of disks for Share/Movies is disk1,disk2,disk5 and the set of disks for Share/TV is disk3,disk4 If you created disk5/Share/TV in addition, then both Share/Movies and Share/TV would be allowed to expand into disk5. Make sense? Link to comment
limetech Posted January 10, 2011 Share Posted January 10, 2011 Thanks Peter. I'll try it. Do you happen to know if the bug was fixed that caused writing to a user share to be significantly slower than writing to a disk directly? Not a "bug" but a result of how the linux 'fuse' subsystem works. However, the latest release of fuse has an improvement in this area that I will be investigating for 5.0-beta. Link to comment
coppit Posted January 11, 2011 Author Share Posted January 11, 2011 Is the main difference between the "split level 0" and "fill up" strategies that the former can be managed more easily via the existence of parent directories? I assume that lacking any parent directories with sufficient space that split level will fail any copy operation, while fill up will create the parent directories as needed. Both can still be controlled using the include/exclude disks parameters. Regarding fuse, bug was the wrong word. "Performance problem"? It's surprising to me that there would be such a big perf hit for basically virtualizing the file system. Usually disk gurus are pretty insane about such things. Anyway I'm going to set up a cache drive tonight so maybe I'll get the best of both worlds. I assume that the mover script follows the allocation policy when moving... Link to comment
coppit Posted January 11, 2011 Author Share Posted January 11, 2011 I played with "fill-up" today, and it didn't do what I was hoping for. I wanted to only switch to a different drive when the folder is full. I created a folder on disk6 and tried to copy a file to the user share. A folder was created and the file stored on disk1 even though there was plenty of room on disk6, the file was small, and the "min free space" setting was 1. So basically if I have separate disks for different types of media, disk1 will eventually have a little of each kind of media. So no matter what I'm browsing, I'm going to have to spin up disk1 and one other disk. This is not what I want. I also don't want split level because I don't want to have to manually create directories. I want a policy that tends to minimize the number of disks different types of media are on, while also having the flexibility to create new paths on other disks when necessary. Here's an example algorithm: 1) Find all disks that contain the complete path for the file being created. 2) If disks from #1 exist, choose the disk with the most free space and that has the minimum amount of space free. Create the file. 3) Otherwise, remove the last directory from the path and go back to #1, searching for a disk that has the shortened path and has free space. Choose that disk, create the missing directory, and create the file. Let's say I have the following setup: //disk1/Movies/Drama 4 GB free //disk2/Movies/Drama 2 GB free //disk2/Movies/Comedy See above (2 GB free) //disk3/TV Shows (10 GB free) //disk4/Movies (6 GB free) Scenario #1: Create the directory Movies/Drama/Shine. The algorithm would create the directory on disk1 because it has Movies/Drama and more space than disk2 Scenario #2: Create a file Movies/Drama/Shine.mkv. disk1 again for the same reasons. Scenario #3: Try to create a 5 GB file Movies/Drama/Shine.mpeg2. This time it would go on disk4. Disks 1 and 2 are considered first because they have the Movies/Drama prefix, but they don't have enough space. disk3 has more space, but disk4 has the parent directory Movies. Scenario #4: I rip the "Lost" box set and it takes more than 10 GB. disk3 would be filled up to the min free disk space, then disk4 would be chosen. In this case all the disks match the "/" directory prefix, but disk4 has the most free space. Scenario #5: I've overflowed on Drama as in scenario #3, and create more Drama files. In this case disk4 would continue to be used until it's no longer the disk with the most space. Thereafter new drama files would be split across disk1, disk2, and disk4. This approach would fill up drives with existing directories, and has the ability to create new ones as needed. It still puts content of different types on disk4 (scenarios 3 and 4), but it has to put the files somewhere. At least in this case the content ends up on the same disk as a last resort. Link to comment
limetech Posted January 11, 2011 Share Posted January 11, 2011 Is the main difference between the "split level 0" and "fill up" strategies that the former can be managed more easily via the existence of parent directories? I assume that lacking any parent directories with sufficient space that split level will fail any copy operation, while fill up will create the parent directories as needed. Both can still be controlled using the include/exclude disks parameters. You are mixing two concepts. Split-level, included-disks, and excluded-disks work together to determine the set of candidate disks that an object can be created on. "fill-up" is an allocation strategy that decides which, of the set of disks previously determined, will be the one on which the object will ultimately be created. "fill-up" always starts at lowest numbered disk in the candidate set, looking for one that still has free space. Regarding fuse, bug was the wrong word. "Performance problem"? It's surprising to me that there would be such a big perf hit for basically virtualizing the file system. Usually disk gurus are pretty insane about such things. Anyway I'm going to set up a cache drive tonight so maybe I'll get the best of both worlds. I assume that the mover script follows the allocation policy when moving... It's because the virtualization is via FUSE, where file systems operate in user space, and data must be copied between kernel buffers<->user space buffers and back (but as mentioned before, newer version of FUSE in conjunction with newer kernel apparently solves this). Link to comment
limetech Posted January 11, 2011 Share Posted January 11, 2011 I played with "fill-up" today, and it didn't do what I was hoping for. I wanted to only switch to a different drive when the folder is full. I created a folder on disk6 and tried to copy a file to the user share. A folder was created and the file stored on disk1 even though there was plenty of room on disk6, the file was small, and the "min free space" setting was 1. So basically if I have separate disks for different types of media, disk1 will eventually have a little of each kind of media. So no matter what I'm browsing, I'm going to have to spin up disk1 and one other disk. This is not what I want. I also don't want split level because I don't want to have to manually create directories. I want a policy that tends to minimize the number of disks different types of media are on, while also having the flexibility to create new paths on other disks when necessary. Here's an example algorithm: 1) Find all disks that contain the complete path for the file being created. 2) If disks from #1 exist, choose the disk with the most free space and that has the minimum amount of space free. Create the file. 3) Otherwise, remove the last directory from the path and go back to #1, searching for a disk that has the shortened path and has free space. Choose that disk, create the missing directory, and create the file. Let's say I have the following setup: //disk1/Movies/Drama 4 GB free //disk2/Movies/Drama 2 GB free //disk2/Movies/Comedy See above (2 GB free) //disk3/TV Shows (10 GB free) //disk4/Movies (6 GB free) Scenario #1: Create the directory Movies/Drama/Shine. The algorithm would create the directory on disk1 because it has Movies/Drama and more space than disk2 Scenario #2: Create a file Movies/Drama/Shine.mkv. disk1 again for the same reasons. Scenario #3: Try to create a 5 GB file Movies/Drama/Shine.mpeg2. This time it would go on disk4. Disks 1 and 2 are considered first because they have the Movies/Drama prefix, but they don't have enough space. disk3 has more space, but disk4 has the parent directory Movies. Scenario #4: I rip the "Lost" box set and it takes more than 10 GB. disk3 would be filled up to the min free disk space, then disk4 would be chosen. In this case all the disks match the "/" directory prefix, but disk4 has the most free space. Scenario #5: I've overflowed on Drama as in scenario #3, and create more Drama files. In this case disk4 would continue to be used until it's no longer the disk with the most space. Thereafter new drama files would be split across disk1, disk2, and disk4. This approach would fill up drives with existing directories, and has the ability to create new ones as needed. It still puts content of different types on disk4 (scenarios 3 and 4), but it has to put the files somewhere. At least in this case the content ends up on the same disk as a last resort. I think you'll find that once you understand the capabilities of the user share file system, it will do essentially what you want. Also, take into account that most of the time, when a file is created, the file system is not told the ultimate size of the file. It is just told to create it, and then the file system sees a series of appends. This is typical. Link to comment
coppit Posted January 11, 2011 Author Share Posted January 11, 2011 I think you'll find that once you understand the capabilities of the user share file system, it will do essentially what you want. Also, take into account that most of the time, when a file is created, the file system is not told the ultimate size of the file. It is just told to create it, and then the file system sees a series of appends. This is typical. Thanks for the reply. I'm still confused about how to achieve the behavior I described. Fill-up creates new directories on disk1 even when there is space on a higher disk that already has the directory I'm writing to. Split level = 0 won't create directories once the existing ones are filled. Can you elaborate how I can achieve the behavior I'm looking for? Here's an example I just tried: /mnt/disk7/Media/Movies/Movies/Sci-Fi Fantasy/Foo (disk full) /mnt/disk6/Media/Movies/Movies/Sci-Fi Fantasy" (disk not full) I set "fill-up" and "split level = 0". When I tried to copy a file to the directory, I got an error about not having enough space. Instead I want unraid to create the directory for me on disk6. Next I set split level to nothing. This creates a Sci-Fi Fantasy directory on disk1 where there is none. This isn't what I want either. It should have created a Foo directory on disk 6, where a Sci-Fi Fantasy directory already exists and which has plenty of space. root@storage:~# ls -d /mnt/disk*/Media/Movies/Movies/Sci-Fi\ Fantasy/Foo /bin/ls: cannot access /mnt/disk*/Media/Movies/Movies/Sci-Fi Fantasy/Foo: No such file or directory root@storage:~# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdh1 1971904 57088 1914816 3% /boot /dev/sda1 488371640 32840 488338800 1% /mnt/cache /dev/md1 293048372 260329240 32719132 89% /mnt/disk1 /dev/md4 488371640 443805908 44565732 91% /mnt/disk4 /dev/md6 732552188 690041264 42510924 95% /mnt/disk6 /dev/md5 390699424 359680828 31018596 93% /mnt/disk5 /dev/md2 293048372 221437496 71610876 76% /mnt/disk2 /dev/md3 732552188 637097604 95454584 87% /mnt/disk3 /dev/md7 488371640 485135436 3236204 100% /mnt/disk7 shfs 3907015464 3097560616 809454848 80% /mnt/user shfs 3418643824 3097527776 321116048 91% /mnt/user0 root@storage:~# mkdir /mnt/disk7/Media/Movies/Movies/Sci-Fi\ Fantasy/Foo root@storage:~# # This is with fill-up and split level = 0 root@storage:~# cp /boot/Pro.key /mnt/user/Media/Movies/Movies/Sci-Fi\ Fantasy/Foo cp: cannot create regular file `/mnt/user/Media/Movies/Movies/Sci-Fi Fantasy/Foo/Pro.key': No space left on device root@storage:~# # Not what I wanted. I want a directory to be created. Let's try it without split level = 0... root@storage:~# mkdir /mnt/disk6/Media/Movies/Movies/Sci-Fi\ Fantasy/Foo root@storage:~# ls -d /mnt/disk*/Media/Movies/Movies/Sci-Fi\ Fantasy /mnt/disk6/Media/Movies/Movies/Sci-Fi\ Fantasy/ /mnt/disk7/Media/Movies/Movies/Sci-Fi\ Fantasy/ root@storage:~# # This is with fill-up and split level = empty root@storage:~# cp /boot/Pro.key /mnt/user/Media/Movies/Movies/Sci-Fi\ Fantasy/Foo root@storage:~# ls -d /mnt/disk*/Media/Movies/Movies/Sci-Fi\ Fantasy /mnt/disk1/Media/Movies/Movies/Sci-Fi\ Fantasy/ /mnt/disk7/Media/Movies/Movies/Sci-Fi\ Fantasy/ /mnt/disk6/Media/Movies/Movies/Sci-Fi\ Fantasy/ root@storage:~# # Not what I wanted either. I don't want it to go to disk1, but rather disk6 where the Sci-Fi Fantasy directory already exists Link to comment
dgaschk Posted January 11, 2011 Share Posted January 11, 2011 root@storage:~# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdh1 1971904 57088 1914816 3% /boot /dev/sda1 488371640 32840 488338800 1% /mnt/cache /dev/md1 293048372 260329240 32719132 89% /mnt/disk1 /dev/md4 488371640 443805908 44565732 91% /mnt/disk4 /dev/md6 732552188 690041264 42510924 95% /mnt/disk6 /dev/md5 390699424 359680828 31018596 93% /mnt/disk5 /dev/md2 293048372 221437496 71610876 76% /mnt/disk2 /dev/md3 732552188 637097604 95454584 87% /mnt/disk3 /dev/md7 488371640 485135436 3236204 100% /mnt/disk7 shfs 3907015464 3097560616 809454848 80% /mnt/user shfs 3418643824 3097527776 321116048 91% /mnt/user0 Both disk6 and disk7 have less than 80GB free. What is your free space setting? Link to comment
prostuff1 Posted January 11, 2011 Share Posted January 11, 2011 As the poster above mentioned take a look at your 'Min Free Space' setting and set it to double your largest file (you may have to reboot to get it recognized). Link to comment
coppit Posted January 11, 2011 Author Share Posted January 11, 2011 root@storage:~# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdh1 1971904 57088 1914816 3% /boot /dev/sda1 488371640 32840 488338800 1% /mnt/cache /dev/md1 293048372 260329240 32719132 89% /mnt/disk1 /dev/md4 488371640 443805908 44565732 91% /mnt/disk4 /dev/md6 732552188 690041264 42510924 95% /mnt/disk6 /dev/md5 390699424 359680828 31018596 93% /mnt/disk5 /dev/md2 293048372 221437496 71610876 76% /mnt/disk2 /dev/md3 732552188 637097604 95454584 87% /mnt/disk3 /dev/md7 488371640 485135436 3236204 100% /mnt/disk7 shfs 3907015464 3097560616 809454848 80% /mnt/user shfs 3418643824 3097527776 321116048 91% /mnt/user0 Both disk6 and disk7 have less than 80GB free. What is your free space setting? My free space setting is 5242880, so disk7 should be considered "full" and disk6 "not full", right? My understanding is that both df and the user share page use KB as the unit. The file I'm copying is 5 MB. Link to comment
lionelhutz Posted January 11, 2011 Share Posted January 11, 2011 Yes, I believe what you want does not exist. However, you would need to manually start filling the array for your "Favor Existing Directories" to have any chance to work so it's far from being a set and forget solution either. I believe your best bet is using the exclude disks. If you want different shares to use different drives then tell unRAID which disks can be used for which share. Your arguement about some files of all types ending up on disk1 really makes no sense. If you don't want "TV Shows" to be on disk1 then exclude disk1. If you want disk1 to be available for TV Shows "just in case", then some day in the future you will get "TV Shows" on disk1 and your argument about not wanting to spin disk1 is lost. Peter Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.