Hi there,

 

I've been a long time user of Drobo, but seeing my 5N is close to dying I decided to go for a less closed system so moving when system failing is much easier.

 

Now I'm trying out Unraid and I kinda like it.. but also kinda don't.. here's my beef with it: like I understand it's not really raid (ergo "un"raid) but this kinda gives me the problem that (esp now I'm transfering data from my drobo to the new unraid system) when a disk is near full, it couldn't fill up perfectly (as say when a file is 10G and you have 9G on a disk, it is in essence 9G not used, whereas with drobo the data is just striped over that space and continued over the next, ok ok that's not how raid works.. but it's just to make my statement)

 

Now is there a way to optimize this? like is there some form of "defrag" for the whole array? I found: 

 which kinda does what I want.. but not in the way I want. Like is there a plugin that basically runs at set times (say 02:00 at night) and then just checks how to make most space available by moving around files? 

 

Furthermore, I'm running unraid in a vm. I know silly, but I only learned of Unraid's VM capabilities later on and still I wanted to test before starting to use it. Is this a big issue or should I just reinstall "if" I decide on Unraid later on? 

 

Added to last, I notice that unraid is very dependent on the USB stick. Which isn't a huge problem, but yeh if my USB stick dies I'd have a problem. So what's the best approach on making the USB virtual? I read up several guides..now I have a disk that is a qemu-img of the usb stick. But this doesn't really work. my usb stick is still utilized it seems. (I tried removing all but config dir from the usb stick and it just doesn't work anymore, but when I stop using the virtualized disk it also doesn't work anymore... so there's some sort of hybrid monstrosity going on)

 

And last question.. is btrfs worth putting time in? I'm now running xfs and it's running fine. But reading up on btrfs it does look appealing. 

 

Thanks for any answers

 

 

Edited September 15, 20196 yr by djmulder

2 hours ago, djmulder said:

Now is there a way to optimize this? like is there some form of "defrag" for the whole array?

Unraid allows folders to span disks. This is called User Shares. The typical way is to write to User Shares instead of to individual disks, and Unraid will decide which disk to put the files on. If one disk gets too full, as determined by Minimum Free for the User Share, Unraid will choose another disk.

 

2 hours ago, djmulder said:

Furthermore, I'm running unraid in a vm. I know silly, but I only learned of Unraid's VM capabilities later on and still I wanted to test before starting to use it. Is this a big issue or should I just reinstall "if" I decide on Unraid later on? 

Running Unraid in a VM is not "officially" supported, but some people do it that way. If you insist on doing it that way there is a subforum here of other users that might help you, but other than that, you would be on your own.

 

2 hours ago, djmulder said:

Added to last, I notice that unraid is very dependent on the USB stick. Which isn't a huge problem, but yeh if my USB stick dies I'd have a problem. So what's the best approach on making the USB virtual? I read up several guides..now I have a disk that is a qemu-img of the usb stick. But this doesn't really work. my usb stick is still utilized it seems.

I can't speak to how things work when you are virtualizing Unraid (see above), but in any case, the actual flash drive has to be involved in some way because that is how Unraid is licensed, by the GUID of the flash. It isn't a problem, as you say, especially if you aren't dealing with running Unraid as a VM. But maybe you don't really understand how little the problem is.

 

Unraid doesn't run on the flash drive, it runs in RAM. The OS is unpacked fresh from the archives on flash into RAM at each boot, and it runs completely in RAM. Changes to your configuration are also stored on flash so they can be reapplied, but other than that, the flash is accessed very little.

 

2 hours ago, djmulder said:

And last question.. is btrfs worth putting time in? I'm now running xfs and it's running fine. But reading up on btrfs it does look appealing. 

Most use XFS in the parity array, but some use btrfs. If you want multiple cache disks (cache pool), those have to use btrfs.

1 hour ago, trurl said:

Unraid allows folders to span disks. This is called User Shares. The typical way is to write to User Shares instead of to individual disks, and Unraid will decide which disk to put the files on. If one disk gets too full, as determined by Minimum Free for the User Share, Unraid will choose another disk.

I work with user shares, but this doesn't solve the problem itself.. files/folders will span over disks as put by a user share when writing, but yeh overtime fragmentation will cause suboptimal space usage. 

1 hour ago, djmulder said:

fragmentation will cause suboptimal space usage

Not clear what you mean by this. Perhaps you could explain exactly what you would like to do.

3 hours ago, trurl said:

Not clear what you mean by this. Perhaps you could explain exactly what you would like to do.

well .. say you have 2 disks of 10TB each.

 

upload 6 files of 3 TB .. both disks will have 3 files and 1 TB free.

upload 1x 1TB and 1 disk is full. 

 

now remove from that same disk a 3 TB file.. 

 

in theory you have 4 TB free.. but 1 disk has 1 TB and 1 disk 3 TB.. so you can't upload a 4TB file.. as the disks are fragmented. While if there was a smart process that would move the 1TB of files to the other disk. it would be more effecient.

 

I'm looking for a plugin that does that basically ^.^

Edited September 15, 20196 yr by djmulder

I assume you just made that example up to illustrate a point. Do you really work with files that large? If not, then a more realistic example would probably suggest the problem isn't very severe, or even worth worrying about.

 

Each User Share has settings that control where new files will be written. These are Allocation Method, Split Level, and Minimum Free. The setting that is most relevant when a disk begins to approach full is Minimum Free. You must set Minimum Free to larger than the largest file you expect to write to that User Share. Unraid has no way to know in advance how large a file will become when it chooses a disk to begin writing a new file. If a disk has less than Minimum Free remaining, Unraid will choose another disk when it begins to write the file.

 

Minimum Free of 20G would be more than enough for most uses, but these days our disks are usually hundreds of times larger than that, so leaving that relatively small amount unused isn't that important when you have multiple disks. And you can even fill that in with smaller files of a different User Share that has a smaller Minimum Free, such as one which might store music or documents instead of movies.

 

3 hours ago, trurl said:

I assume you just made that example up to illustrate a point. Do you really work with files that large? If not, then a more realistic example would probably suggest the problem isn't very severe, or even worth worrying about.

 

Each User Share has settings that control where new files will be written. These are Allocation Method, Split Level, and Minimum Free. The setting that is most relevant when a disk begins to approach full is Minimum Free. You must set Minimum Free to larger than the largest file you expect to write to that User Share. Unraid has no way to know in advance how large a file will become when it chooses a disk to begin writing a new file. If a disk has less than Minimum Free remaining, Unraid will choose another disk when it begins to write the file.

 

Minimum Free of 20G would be more than enough for most uses, but these days our disks are usually hundreds of times larger than that, so leaving that relatively small amount unused isn't that important when you have multiple disks. And you can even fill that in with smaller files of a different User Share that has a smaller Minimum Free, such as one which might store music or documents instead of movies.

 

Yeh it was just an example to illustrate the point. But yeh my data migration from drobo -> unraid is kinda proving the point as I'm overcapped 4TB and I'm trying to squeeze every GB from network devices. An optimizing script would certainly help here.

 

I'll mess around with the setting, but still doesn't really "solve" it tho. Hmm I guess when the NAS is up and running it will be a non issue, but still. I can imagine at NAS cap such a script would benefit more ppl

3 hours ago, djmulder said:

data migration from drobo -> unraid is kinda proving the point as I'm overcapped 4TB and I'm trying to squeeze every GB from network devices.

Not really following this and how it might relate to the discussion we were having. The Minimum Free setting only comes into play when deciding where to write a new file. And if you don't have that set larger than a file you try to write, Unraid can try to write to a disk that won't hold the file, since it doesn't know how large the file will become. When this happens, the write simply fails. It doesn't try to move anything, or try it again on another disk, or anything like that. So that will have no impact on write speed, but it will have an impact on whether or not a write will fail due to out-of-space.

 

Unraid parity is updated in realtime, and that does affect write speed. There are 2 possible ways you can configure this, as explained here:

 

https://forums.unraid.net/topic/50397-turbo-write/

 

Are you using a cache disk or cache pool? I recommend not caching the initial data load since cache will not typically be large enough to hold it all until it can be moved later, and caching / moving just gets in the way since it competes for the same resources when you are also trying to write new data. Some people even do the initial data load before adding a parity disk since parity slows down writes.

 

It might be instructive to know what settings you have made for a user share you are writing to. You can provide that information and a lot more by going to Tools - Diagnostics and attaching the complete diagnostics zip file to your next post.

5 hours ago, trurl said:

Not really following this and how it might relate to the discussion we were having. The Minimum Free setting only comes into play when deciding where to write a new file. And if you don't have that set larger than a file you try to write, Unraid can try to write to a disk that won't hold the file, since it doesn't know how large the file will become. When this happens, the write simply fails. It doesn't try to move anything, or try it again on another disk, or anything like that. So that will have no impact on write speed, but it will have an impact on whether or not a write will fail due to out-of-space.

Well the earlier describe situation where you could have more space free is what I'm running into with the initial data import (an example would be where I have a 40GB file and there's 40GB free, but yeh scattered throughout the disks, I had to manually move around data quite often to free up that space)

 

About logs, sure, next time (at work now), but my problem is only on the surface so I don't really saw the need for logs. Not like I'm running in actual technical difficulties, it's more just being peefed with lack of tech capabilties. (and as a dev, it's extra frustrating, as you know it can be done technically )

 

 

5 hours ago, djmulder said:

Well the earlier describe situation where you could have more space free is what I'm running into with the initial data import (an example would be where I have a 40GB file and there's 40GB free, but yeh scattered throughout the disks, I had to manually move around data quite often to free up that space)

Folders can span disks, but files cannot, since each disk is an independent filesystem. The recommendation would be to set Minimum Free to more than 40G if you expect to write a 40G file. Then Unraid would choose another disk if one disk got to 40 or less free.

 

Another thing to consider is Split Level takes precedence over Minimum Free, so even if Minimum Free says a disk is too full, Split Level could make it use the disk if Split Level says the file belongs with other files already on the disk.

 

Personally, I don't bother with Split Level and just let it put files on different disks if it wants. The only effect is a possible spinup delay when accessing the next file. And the default Highwater Allocation Method will often keep files together anyway.

 

If you fill up all disks so there is just a little bit remaining on each and none would hold a 40G file, then the recommendation would be to add a disk or replace a disk with a larger one to get more capacity. You can manually move things around to get free space consolidated to a disk so it would hold the 40G file, but that would only be a temporary solution, and you might as well bite the bullet and increase capacity.

14 minutes ago, trurl said:

If you fill up all disks so there is just a little bit remaining on each and none would hold a 40G file, then the recommendation would be to add a disk or replace a disk with a larger one to get more capacity. You can manually move things around to get free space consolidated to a disk so it would hold the 40G file, but that would only be a temporary solution, and you might as well bite the bullet and increase capacity.

Ofc, but now I'm basically going from device A -> B moving disks along the way. So capacity increases overtime, so in that small window where I can't remove a disk from the old device to put in the new.. having the most optimal space available helps, now data is scattered over my network til I reach the point where I can remove a disk from the old device. (which is hard, as my drobo says: at 100% capacity, even tho only 5% is used >.< ) 

27 minutes ago, djmulder said:

remove a disk from the old device to put in the new

Since you are reusing data disks from another system, I have to ask.

 

Do you have another copy of anything important and irreplaceable? Parity is not a substitute for backups.

 

Sounds like your problems would mostly go away if you just added a new empty disk.

33 minutes ago, trurl said:

Since you are reusing data disks from another system, I have to ask.

 

Do you have another copy of anything important and irreplaceable? Parity is not a substitute for backups.

 

Sounds like your problems would mostly go away if you just added a new empty disk.

Ofc, parity never is a substitute for backups. But it does cover for loss of disk, riight? (now you make me doubt, I'm going by principles of raid with parity in general, I assume that unraid does similar, so if 1 disk dies, parity + remaining data can be re-calculated)

 

And yes I do have copies of irreplacable stuff. .. I just don't want the world to end if 1 disk fails.

 

And also yes, getting a new empty disk solves a lot, but I don't have one right now.

 

Tho I don't see them as "problems" it's more like a design choice I understand but am peeved with and trying to figure if there's a work around. Like a script that does smart "sorting" of the data, filling up disk by disk in stead of fragmented over disks. In my head it doesn't sound to hard, and if I weren't lazy and put in effort I could probably write one as it's basically nothing more than a somewhat more complex sort.

Edited September 16, 20196 yr by djmulder

5 minutes ago, djmulder said:

filling up disk by disk

One of the choices for Allocation Method is Fill Up.

 

There is Help in the webUI for most things. You can toggle Help on/off for the whole webUI with the Help (?) button on the main bar, or you can toggle help for a specific setting by clicking on the label for that setting.

 

6 minutes ago, djmulder said:

if 1 disk dies, parity + remaining data can be re-calculated

Yes, the data for a missing disk can be calculated from parity plus all the remaining disks.

 

In order to reliably rebuild a failed disk, it must be able to reliably read every bit of parity plus all the remaining disks. So it is very important that you only use reliable disks and keep up with any disk problems as they arise. I always say this as "be careful and diligent". Being careful means double check all connections anytime you are mucking about in the case, and being diligent means set up Notifications so Unraid can alert you immediately by email or other agent when any problem is detected. You must deal with each single problem when it arises or you could wind up with multiple problems that parity might not help with.