FlexGunship

Okay, that's clear apart from one item then. Thank you. IF: /mnt/disk1/myshare/document1.txt exists THEN /mnt/pool/myshare/document1.txt shouldn't, right? It implies the mover already moved the file. I ended up with a copy in disk1 and pool SOMEHOW. They were different revisions of the same file, but same name. I was able to manually resolve it (but, it invovled a lot of careful manual manipulation). I wonder if I stupidly did a manual rsync against /mnt/cache/ (/mnt/pool/) one time. This also (mostly) resolved my "always moving, but nothing moved" issue and my cache utilization is much lower now.

Interesting. During the SMB transfer operation, my assumption (naive) would be that it would comparing the file list against the one on the array - but maybe it's not? File info.dat exists on the array in share Documents (which uses cache). The same file, an unaltered second copy of info.dat, is moved to the unRAID share Documents via SMB transfer. Even though the share has info.dat, it may still move a second copy to the cache since the operation wouldn't generate a conflict? Then the mover can't move info.dat from cache to array because the operation would necessitate an overwrite? Okay. Thanks again. I was going to setup a cron job that uses rsync to do the samw.thijg, but I suspect it would see the file list of cache contents and not the file list of the array then. Last Q, can the "minimum free space" argument prevent a transfer? Or does it simply trigger the mover when exceeded? And if it's the second one, is there any harm in keeping the minimum free space arbitrarily high? 850GB on a 1TB cache to force the move operation frequently?

Thank you for the response. That's precisely what I have for the shares of interest... but mover looks at every single file and moves nothing. Presumably because they are new. I have a 1TB cache (2x 1TB nvme drives). During heavy traffic, my cache will fill up, and it will stay full for days. Invoking the mover gives me a string of "already exists on the array" and no reduction in cache utilization. The mover basically runs 24/7 and my cache stays 50%+ full. I have a folder that I copied from another system called "Backup" which is 130GB. I haven't touched it and its presence on the cache drive hasn't diminished in over 24hr. I've been running mover all day and it's just chilling there. Is there a way to change that behavior? artemis-diagnostics-20240906-1545.zip

I've tried searching under a few potential subjects, but I can't find what I'm looking for. I'd really like my cache to behave *purely* as temporary storage for transfers (at least for some shares). I'd like to be able to dump my backups from my network quickly (cache speed), but I have ZERO interest in keeping it on cache - I just love my 2.5Gbps transfers. I'm presently using the "Mover Tuning" plugin (which is good), but even then, I can only fudge the type of behavior I'd like and it barely works. There are a few shares (Documents, Photos, CAD Projects) where I like the behavior of keeping recent files in cache. So that's all good. I feel like what I want was always possible in the past (use cache, but prefer array - or whatever), and now it's gone. Can anyone help? Am I just being particularly low-IQ on this?

I understand perfectly. Thank you for the quick and clear reply.

Hi all, I've searched, but I'm not even sure how to look up my question. I have a legacy "Unraid Pro" key (8-drive array, 4 cache) and a more current "Unraid Unleashed" key (4-drive array, 2 cache). I just bought a new server chassis which supports 12 LFF drives and I'm going to combine everything. I've already consolidated all data on the "Unleashed" server. I'll start by preserving the "Unleashed" server and then add the drives from "Pro" Once done, I'd like to move my pro key over and keep the config, dockers, VMs, etc of the "Unleashed" server Can I do this by downloading the key and putting it in the /config folder?

Whelp - that was it. Thanks. I'll mark this solved. Solution: Cat8 cable versus (damaged?) Cat6 cable.

It's a cat6 I've used before. But I'll try another one. I had the same thought when I had the issue yesterday and I've already ordered some cat8 cables.

Long story short - I had some unfixable corruption of my btr file system (caused kernel panic under load; you can see my previous posts of the last couple of years) - I'm standing up a new server with xfs, moving everything over, and repurposing the old one. New server has 4x 10Gbe NIC but they are all auto-negotiating down to 100Mbps. I'm only expecting 1Gbps link-speed given the intervening hardware with a lower practical limit (~600Mbps) due to the temporary network topology. Firstly, is the X540-AT2 chipset supported in Unraid? Secondly, is there anything in my attached diagnostic file to suggest a correctable root cause? diagnostics-20240706-1241.zip

No overclocking. It's a stock i7-6700 (non-k) with a stock cooler on a stock Dell mobo. I haven't run memtest recently. But I HAVE run memtest since I had the issue. I have also removed each stick (running with 48GB at a time) and have noted a crash in every case. Also... I bought this processor, mobo, and RAM to address the crashing issue. I had the same issue on an i3-6100 previously with 32GB of different RAM on an HP motherboard. I also bought an LSI SAS card to try to solve this issue as the Dell mobo has a Marvel data controller which is notorious for not working in unRAID (I'm told). To be fair, I don't know for a *fact* that the failure mode is identical as the i3-6100 HP days, but the rate of failure and manifestation is the same.

syslog I guess I had it running since last year... so it was huge. I trimmed anything before 2/12 for the purpose of this upload. If you need more of the log... or need to me start it clean, please let me know.

Just updating that the syslog server is enabled, and I'm waiting for the next crash at this point.

Polite Bump I'm still having this issue about every 24 to 36 hours. No lost data, but I would really appreciate any other insights anyone has.

First question first - it seems to be an artifact of early PCIe SSDs. It's actually a single device on a single PCIe slot, but internally it has 4 devices mounted in raid. In my experience, unRAID recognizes a "head" device and 3 "others". If I mount one of the "others" I get 240GB and a single device - if I mount the "head" device, the internal firmware of the SSD kicks in and mount all devices as a single 1TB device. It kind of took a while to figure out how to make it work; I don't pretend to understand the internal machinations. EDIT: Anyway, it made cache pool thing tricky to manage when the array went down. So, I just nixed. No deeper meaning. If, for any reason, you believe this is contributing, I can pull it. Previously my docker.img was on the array. Likewise, I can also collocate the appdata folder if you think it could be related. But the problem, again, existed long before this recent move to the non-array device. I've recently switch to ipvlan - I didn't notice a change for better or for worse after the change. DOUBLE EDIT: Was it clear what the mode of failure was from the first syslog? It's not clear to me that there was evidence of failure in the diagnostics ZIP.

Lol... do you know how many times I'm mentally admonished someone for forgetting their diag.zip? My bad - apologies. athena-diagnostics-20230203-2333.zip