jkexbx

Still a problem. Thanks for this!

I have a usecase that involves a lot of calculations that are causing excessive TBW on my drives. I want to provide a network ramdisk to share via smb for my other servers to read and write to. Would it work to add these lines to smb-extra.conf? [ramdisk] path=/dev/shm browseable = yes public = yes writeable = yes

Also started getting the warnings randomly Parity_Check_Tuning_1755594021.notifyThis notification is invalid and cannot be displayed! For details, see the logs and the notification file at /tmp/notifications/unread/Parity_Check_Tuning_1755594021.notify

How do you create separate containers using different ports? When I go through add contains, and select the existing mongo template, I can't change the container port. I can only change the host port, and then end up connecting to the same instance through a different port. If I remove the Host Port 1 line and re-add, I can atleast modify the host port. But I can't get the mongodb port changed to a different port. mongod --port won't work in the console or at startup.

I have the same question. I don't want to upgrade to 7.0.0, just 6.12.15. I'm on 6.11.5 now

So I've had some interesting leanings, and found something workable. Those commands as a pair are intended for the array to be mounted If the array is in maintenance mode and you try to run umount /mnt/disk# you receive: no mount point specified That means the only reason you would ever need umount /mnt/disk# is if the array was mounted If you start the array in maintenance mode you can run just the zero command dd bs=1M if=/dev/zero of=/dev/md1 status=progress and the write speed is as expected You can also exit the terminal and the command will stop after 10 minutes or so. When the array is remounted, the disks show Unmountable: Unsupported or no file system When you run the zero command on that unmountable disk then with the array running the zero runs at expected speed. While the command is running, the scheduled parity check won't run. All this means that when the array is mounted, and you run the umount /mnt/disk# something is happening that results in the disk almost, but not quite being unmounted. The zero command does run, just slowly. The zero command does not terminate You cannot stop the array because the zero command is running without any way to kill it My procedure that ended up being reasonable is: Verify disks are empty Stop array Start array in maintenance mode Run dd bs=1M if=/dev/zero of=/dev/md1 status=progress Wait for first 20G of data to be zeroed Close command window Wait until disk activity goes to zero(around 50G of writes) Repeat with next disk Reboot (you could also stop array and then start, but for me that results in a graphical glitch) Start array normally See disks you're trying to zero as unmountable Run dd bs=1M if=/dev/zero of=/dev/md1 status=progress on disks 1 by 1. Remove disks from array Reset configuration What's funny about this is I still don't ever need to use the umount command. I've done at least a partial parity check and have 0 sync errors. Running the zro command for a short while removes the drive formatting, so it's no longer mountable. All with dual parity. Of course you can always just keep it in maintenance mode, but if you're trying to zero a dozen disks like me that means your server is down for a week.

Yeah, all the above has been setup and tested previously. Just trying to avoid the headache of restoring data. I just don't want to take any needless risk and it's surprising that removing a disk while keeping parity intact is such a difficult thing to do.

Definitely simpler, but incredibly risky. If any data disks die during rebuild, you don't have a valid parity left. I'm trying to maintain parity while removing data disks.

Per the Unraid Docs it's how you zero a disk to remove it from an array. The script is broken in a couple of different ways, so I avoid that now. Do you know if there's a new way to zero a disk? It's supposed to cause a parity update. I'd expect it to run at 50 mb/s like it does after the hard reboot. The problem is something is happening with the umount to cause it to run at 400kb/s.

Thanks for taking a look, but It's not relating to other drives activity. I can kill all dockers, VMs, and scripts, and it will still continue at the same speed. There is some additional interaction going on that causes a consistently slow write speed of 400-500 kb/s. I believe it's related to the umount not working as expected. If you need me to run through the sequence and download logs at a specific time I can. But I'm trying to avoid that without something to also try because the only way is to hard power down the server after running the first dd command. No matter what I do, I can't get the server to clean shutdown.

The commands to zero a disk are: umount /mnt/disk15 dd bs=1M if=/dev/zero of=/dev/md1 status=progress When I run the dd command, the progress runs at 400kb/s with no way to kill it. I end up following the below steps to successfully zero a disk. I have the dd command run fine after an umount in the past. Does anyone know if there's a specific trick to it? Run the umount command The disk size changes to a random number I then run the dd command, and progress is running at 400kb/s I fail to kill the running dd using every method available I stop the array, but it fails I hard shutdown the server It comes back up I try to mount the array, but it's in some half broken state where VMs can start, but the GUI still allows you to modify disks I then do another reboot through the GUI Everything comes back normally The disks I'm trying to zero show unmountable: wrong or no file system I run dd again on them and it runs fine at a normal 80mb/s tower-diagnostics-20231223-1749.zip

I'd mentioned that post previously. Following it still doesn't allow unraid to stop the array. I suspect the problem is relating to the dd command running at a root level. No matter what I do, the disk I run the command on continues to see activity at 400kb/s.

Do you mean this command for unmounting? root@Unraid-Server:~# fusermount -uz /mnt/cache/

Are you referring to this thread? Or do you mean an alternative to using the umount /mnt/disk8 command? I've found that command is extremely unreliable when running the dd bs=1M if=/dev/zero of=/dev/md8 status=progress command. What happens currently: Run the umount command The disk size changes to a random number I then run the dd command, and progress is running at 400kb/s I fail to kill the running dd using every method available I stop the array, but it fails I hard shutdown the server It comes back up I try to mount the array, but it's in some half broken state where VMs can start, but the GUI still allows you to modify disks I then do another reboot through the GUI Everything comes back normally The disks I'm trying to zero show unmountable: wrong or no file system I run dd again on them and it runs fine. I did use the command fine previously, and the only thing different was I first mounted the disks in SMB to double check they were empty. Once the current command finishes, I'll try that. Not sure how that makes a difference, but I think that's the only thing different between when it worked previously and now.