[Question]: Space reservation on UNRAID array/ high water functionality

[xerox445]

Question

Hello,

I have setup a vdsm docker container on my unraid server, and its been working wonderfully thus far. I created the image with 20tb of storage, and that shows up correctly inside DSM, but outside on my unraid GUI, it only shows space on the first drive in the array reserved. If that is just a bug or known issue, I am fine with that, it does not bother me, but what I am wondering is what will happen when I use more space inside the DSM docker container, and fill that first drive up? Will Unraid/docker/dsm start utilizing the next drive via the high water method? I am concerned that its going to break the container/ my server if the docker runs out of space on the first hard drive while doing a large remote backup (12+tb). I am about 7tb in, and with the other contents added up, I should be hitting the storage limit for this first drive soon.

[kroese]

I never used unRaid in my life, and have no experience with ZFS or Raid, so I am not the best person to help you..

But I think it all depends on where you mounted the /storage folder. If you mounted it to a folder on the first drive, and you set ALLOCATE=N then yes you can have 20TB image on a 12TB drive, but as soon as the drive is full you get write errors.

If you did not set ALLOCATE=Y and set the /storage to a location that is a RAID array of all 4 drives, then it should work. But then I agree the screenshot looks weird (but again, I dont know how unRaid works so maybe it is normal).

The safest option I guess would be to create multiple disks (see the FAQ), so you get seperate volumes which each are smaller than 12TB. If one of those images gets corrupted, at least you dont loose the other ones.

[xerox445]

Thank you for the information, I will look into it. Do you think I should pause/stop/abort my backup and try to adjust this now, or is this likely something that is already going to either work or not, and I should just let it play out?

[xerox445]

Well about 7 hours ago, it looks like the docker crashed. Its in an "unhealthy status" and when restarted, it hangs, I attached the logs from when I restart the docker. dockerstartuplog.txt

[kroese]

I dont see any real errors in the log (except it doesnt continue). But it shows: UNRAID_Synology login: so at least it boots to the point where you can login to SSH I suppose.

This container is just a hobby-project, and was mainly ment as a way for people to just play with DSM a little for demo-purposes. I did not expect people to use it for production or to store any critical data on it, let alone 20TB :o But if you keep the data.img small, you can easily make backups of it (while the container is not running!). So in that case there is little risk involved, because you can always replace it with a previous copy when something goes wrong. But to make regular backups of a 10TB file is much harder.

I know the Windows tool DiskGenius is able to read the BTRFS .img files from this container. So I think using that tool you can still dump the data even if DSM refuses to read it.

Another possibilty is that the system.img is corrupt (and not the data image). In that case it would be even easier to fix by just deleting the system.img so that the container automaticly downloads a fresh copy of DSM and performs a clean installation again. This will preserve any data you had, so as long as your data.img is still good, it will fix the problem.

Another thing to try would be to set DISK_FMT to qcow2. This will trigger a conversion of the disk files raw format to qcow2 (which will take an extremely long time for 10TB) but there is a small chance it fixes something.

In all the above cases I would create a backup of the /storage directory first before you try them, so that you can always go back to the current state if it makes things worse.

[xerox445]

@kroese First off I want to thank you for your work on this docker, the stability of this is really amazing, and please don't take any of my previous posts as criticism of your work. I appreciate you trying to help me out with this and I am well aware I am using this in a way that is mostly outside its intended use case. I am in a unique situation where this data is not mission critical on this side, its a backup for a friend, who currently has no real redundancy besides a 4 drive array with 2 parity drives in his synology. Also, doing this setup I've really learned so much along the way, I am really enjoying working on this.

I followed your instructions, and deleted the system.img file, it re-downloaded a new fresh copy and did a clean install. My data appears to still be there, but it seems that it is not spanning to the second disk on my server. I have a feeling this is more a function of the unraid file system, and I ran into this issue because the backup I was running (hyperbackup inside dsm) is treated as a whole image, and not individual files, so unraid could not "split the file/ folders" as it reached the capacity of the first drive. I am going to try to force unraid to "spill over" to the second drive by transferring files from a windows machine to shares on the array via SMB, and see if that will allow me to continue the backup once I set it back up again. If that does not work, I will try to figure out another solution, perhaps adding more then 1 virtual drive to the docker. Although, I do not want to set up an "array" within DSM, can I add perhaps 2 8tb drives, mounted to different drives within my unraid shares, and have them show up as a non redundant pool in DSM? Anyway, thank you again for replying, I really appreciate your help, and your work on this container in general. The smoothness of the install of this in comparison to running DSM in a VM on unraid is like night and day. Figuring out this hiccup is nothing in comparison to configuring dsm to run the other way, and this package you have created is really top notch. Thanks again, and I will report back with some testing later.

[kroese]

Thanks! VirtualDSM has no support for "arrays", so if you add multiple disks, they will always become totally separate (non-redundant) volumes.

[xerox445]

So, update. I am currently in the process of moving data (unrelated to this backup/virtdsm project) off that disk onto another disk in my array, with a plugin called unbalanced, to give it some room to breath before I attempt to fix this. I think I can add 2 disks to DSM, 8tb each (assigned to specific disks on the array) and split the backup folders on the source synology to make this work.

Also, it seems because the drive was so full, when I deleted the system.img file, it triggered the high water function, as some of the files show as on my second disk as shown here.

My question now is, can I successfully lower the disk size of 20tb when I originally created this monster and preserve the data contained in the data.img file?

Again thank you for your help!

[kroese]

No, unfortunately not.. You can increase the DISK_SIZE variable to a larger size, and it will automaticly expand the disk. But you cannot decrease it too smaller size.

[xerox445]

@kroese So over the past week, I have been able to successfully continue the backup, and I am at the point where I want to make a few changes to the way the backup jobs are run.

I read your FAQ about adding another disk, but in the unraid environment, I an struggling to find the docker compose file. It seems to me like the template that unraid creates, will let you add another "Path, variable, label, or device". I believe if I copy the variable "DISK_SIZE" template, add another one, at say 6tb, and add another container path, it will create those 2 lines in the compose file and make a second disk inside DSM, with that space being located on another disk in my array. I've been hesitant to do this, because I am afraid of breaking the docker and not being able to recover from it; not because the data is mission critical, but more so the time investment we have made to transfer 10tb over the internet at 80gb an hour :) Here are the screen shots of the unraid interface.

Do I name the container variable "DISK2_SIZE" for the second disk I want to add, and then just another path for the second disk location? I believe when you update the container, it gives you a display like this to show what you have made: (this is just the example from your git)

version: "3" services: dsm: container_name: dsm image: vdsm/virtual-dsm environment: DISK_SIZE: "16G" devices:

• /dev/kvm cap_add:
• NET_ADMIN ports:
• 5000:5000 volumes:
• /var/dsm:/storage restart: on-failure stop_grace_period: 2m

If the templates work, I think this will show the second disk and a second path? If I make the changes, do I risk breaking it badly enough that I won't be able to undo the changes I want to make to create a second disk, and break the entire thing?

I believe I can create a new "vm disk size" variable, and "disk location path", as shown in the screen shots and it will add these into the compose file when I start the docker back up? Any thoughts? Thank you again for your help!

[kroese]

Yes, just like you said. Create a second variable with DISK2_SIZE as the KEY (this is confusing in unRaid because some people put in NAME and leave KEY empty). And then the second container path /storage2 and you will be all good.

There is nothing you can break by doing this. The worst that can happen is that the new disk does not appear, but it will not influence your existing stuff.

[xerox445]

Thank you, I figured it would be best to create another "test bed" for this, and made another container to test this out, made it with 1 200gb disk, then went back and edited it, added a second disk, at 150gb but at first it didn't work. Your reply came just in time, I didn't use /storage2 in the path. Looks like it works perfectly now. Thanks again.

What a fantastic piece of work this is.