jbrodriguez

Thanks, the app 'reads' from unassigned.devices, so it's now the primary suspect for the crash I'm unable to replicate the issue though on my server (6.8.3) with unassigned.devices installed, but I don't have any actual unassigned device. Can anyone having problems run the support script on their server ? Here's how to do it This will hopefully help me track down the root cause.

Well, the app seems to be crashing, it looks like some value returned from the server is different than what it was before. Can you post your Unraid version? Maybe something changed recently ? I'll check locally later today or possibly tomorrow.

That's odd. Have you made any other change to the server ? Upgraded Unraid ? Changed SSL settings ? Can you check the plugin log for any potential issues (the log is at /boot/logs/controlr.log) ?

I think it has something to do with SSL vs no SSL, I'll take a look

It doesn't "balance" data across drives, it uses the first drive with enough space, if not enough, uses the second drive with enough space and so on

It looks like there's not enough space, can that be your case ?

so, this was too intriguing for me, i had a test for this scatter, so i tried your data this is the result, it's quite low level info but the idea is there this is the body of the test func TestKnap(t *testing.T) { blockSize := int64(4096) fBlockSize := float64(blockSize) disk := &domain.Disk{ ID: 2, Name: "md2", Path: "/mnt/disk2", Device: "sdc", Free: 3498492334080, Size: 7999426170880, BlocksTotal: 1952984905, BlocksFree: 854124105, Serial: "SAMSUNG_HD15", Status: "DISK_OK", } items := make([]*domain.Item, 0) items = append(items, &domain.Item{Name: "proxmox-backup-server_1.1-1.iso", Size: 710651904, Path: "/mnt/disk1/isos/proxmox-backup-server_1.1-1.iso", BlocksUsed: int64(math.Ceil(float64(710651904) / fBlockSize))}, &domain.Item{Name: "proxmox-mailgateway_6.4-1.iso", Size: 1024268288, Path: "/mnt/disk1/isos/proxmox-mailgateway_6.4-1.iso", BlocksUsed: int64(math.Ceil(float64(1024268288) / fBlockSize))}, &domain.Item{Name: "proxmox-ve_6.4-1.iso", Size: 928993280, Path: "/mnt/disk1/isos/proxmox-ve_6.4-1.iso", BlocksUsed: int64(math.Ceil(float64(928993280) / fBlockSize))}, ) reserved := int64(1073741824) packer := algorithm.NewKnapsack(disk, items, reserved, blockSize) bin := packer.BestFit() assert.Nil(t, bin) } and below you can find the result of the test, it's failing because it expected no bin (group of files/folders) to be created , but it actually created one (just a quick way to test this ) it created a bin with 3 items, sized 2663913472, which is the sum of the size of the 3 files ❯ go test -v === RUN TestKnap unbalance_test.go:764: Error Trace: unbalance_test.go:764 Error: Expected nil, but got: &domain.Bin{Size:2663913472, Items:[]*domain.Item{(*domain.Item)(0xc000012c00), (*domain.Item)(0xc000012c40), (*domain.Item)(0xc000012bc0)}, BlocksUsed:650370} Test: TestKnap --- FAIL: TestKnap (0.00s) FAIL exit status 1 FAIL unbalance 0.003s i tried also using bytes instead of blocks and it worked too. so, with regards to the issue you're having, there's something odd about how many blocksUsed are being reported for each of those files (unfortunately i'm not logging that piece of data) i set blocksUsed to 0 for those items as another test and i got the exact same behavior you're currently experiencing, i was able to fully replicate it. so, this is very strange because in your logs you have I: 2021/05/15 09:10:45 planner.go:520: planner:array(4 disks):blockSize(4096) blockSize set to 4096, which means, items should have a blockSize (planner.go:325) if blockSize > 0 { blocks = int64(math.Ceil(float64(size) / fBlockSize)) } else { blocks = 0 } and this is all to say that i'm out of fresh ideas somewhere, somehow, something is getting misreported, just can't figure out what/where yet 🤷‍♂️

yes, block size is the same in all of them it's definitely baffling and intrigues me a lot 🤷‍♂️ 😀 I think i have enough data (with your logs) to "test-replicate" it not likely this weekend, but i should have something by the next one

yes, it's odd can you run stat -f /mnt/disk1 stat -f /mnt/disk2 stat -f /mnt/disk3 stat -f /mnt/disk4 and check if the blocksize is the same for all of them ? it's the only thing I can think of right now, some discrepancy in block size, although it would still fit based on bytes, since you have so much free space

yes, sounds odd. check the logs for any clues, /boot/logs/unbalance.log and see what the planning stage outputs

completely slipped my mind, you need to also select at least a folder from the "source" disk

i'd try uninstall/install then, see if it makes a difference not sure what the issue can be.

did you click on one "from" disk and at least one "to" disk ?

odd, you should be able to click on the plan button. screenshot ?

generally not recommended, but if they're using the source/target disks, it should be ok

yellow icons mean that that particular transfer had some issues, permissions, dates, etc, the log should show more info

I posted a new version of the plugin a couple of days ago, it was mostly plugin structure changes, no new features or fixes, just to give everyone a heads up on why you're seeing an update

looks like it doesn't like the ssl certificate, not sure why. A short term solution would be to set Unraid to SSL = off in Settings, restart unbalance and connect again. That should work. I'll try to check if there's an ssl issue over the weekend

it looks like the server is not running for some reason try this ps aux | grep unbalance this is in order to get the <params> unbalance is running with. Use them in the command below killall unbalance /usr/local/emhttp/plugins/unbalance/unbalance <params> run the web ui again and report any error on the server command line

Can you heck if it's crashing, in Chrome, it's in View > Developer > Javascript console

In Chrome, you go to View > Developer > Javascript console

In the settings page, you can pass custom rsync flags https://github.com/jbrodriguez/unbalance/#settings

It may have crashed, can you check the developer's tool console for any errors ?

I see, probably there's a new 'api' to get the other cache pools. I'll take a look, but it might take a bit of time.

Hey, I've published unBALANCE 2021.04.21 (5.6.4), but it's just some plugin structure changes, no new features/fixes