Hastor

If it is part of a protected array, then you don't want to just copy it. Parity doesn't know what files are, it's just protecting the data on the drive, whatever it may be. If you rearrange the data, you would have to tell it to recalculate the parity - I'm not sure of the exact steps of that. Rather than copying to a new drive and using it, I think it would be better to copy to that new drive, then copy back onto the array. I still don't like that the data will be unprotected for a bit while it only exists on the external drive, and you'd need to copy to that drive through the array so that parity is calculated. I'd also love to have an easier way to defrag. My array has large drives and I can't afford any place to temporarily store the data, but it's getting pretty full and been in use a long time.

Ah, you're correct. I don't think I ever touched that setting, is it default to never spindown? I know when I haven't used it for a while, I typically hear more noise, and have to wait a second before it becomes responsive, same when accessing a file from a different disk on the array, so it always seemed like a spindown delay was there, but I'd never seen the * as the temp.

All of my disks are SATA, I even hear (and wait) for them to spin up, but I have never seen a * for the temperature. They always maintain a temp a few degrees above room temp for ones in external enclosure (28c in a 24c room), and the ones in the server tower a couple degrees more. Even if I haven't accessed them for days. Even if I click spin down, I never see a * - is something wrong? Sharing my config. All my drives are Seagate, either Ironwolf or Exos. megachurch-diagnostics-20230709-1645.zip

I touched on this in another thread where I was asking a few things, but based on the answer, and what I see when I click the ? for info in Unraid on my array, the temperature should read * when my drives are spun down. I've never seen a * under my temperatures for any of my drives, always temperatures, for years. I'm using Seagate HDDs for my array, and Crucial SSDs for my cache, and have used Samesung and WD SSDs. Always seen a temp on everything. Most specifically, in Unraid it says (copy/pasted): "We do not read the temperature of spun-down hard drives since this typically causes them to spin up; instead we display the * symbol." The thing is, I could swear I hear my drives spinning down. When I haven't accessed a drive for a while, and request a file from it, there is typically a brief delay before the first file comes in, then it is instant from then. This seems like spin up/down behavior to me (and sounds like it when I'm nearby enough to hear it). But I've never seen a * in the temp to indicate a spun-down drive. Someone replied in my other thread saying they saw * when spun down, so what gives? I appreciate any help! Thanks! Diagnostics attached megachurch-diagnostics-20230518-0110.zip

Just curious about a couple things: - If I hover around the HDD temps and click when the cursor is a ? for more info, it says that temperatures won't be read for spun down drives, and a * will be shown instead. I just noticed that. For a couple years now, I've heard my drives spin up and down, but always seen a temp, never a * show up. My drives ARE spinning down right? - If I click 'spin down all drives' or 'spin up all drives', how long is that for? If a drive is in use, or a file from it is requested, I'd assume it would spin up. Does spinning up just spin down after the normal idle time before a spin down? Thanks, just wanna be sure I understand what some buttons do, and that my drives are spinning up/down properly.

This is when they are green. It says "Normal Operation, Device is active. Click to spin down device." If I hover the green dot. However, capabilities/attributes show not available most of the time. I even tried immediately after copying a file to the cache, and refreshing a few times to see if it appeared, so I know it is active, but neither drive will give me stats. I also tried after running mover, with a small file on the cache. Sometimes they do show though... I wish I knew what determined when that was. Updating to note that if I do a transfer that takes long enough, and check while the file is being transferred to the cache, I can see the info at that point. They are always green though. My previous Samsung SSDs for cache had this info avilable every time I looked, these WDs seem to work just fine but only provide info when transferring.

Well this is odd @JorgeB, now they are unavailable again. I haven't changed anything or rebooted, though I did copy some files to the cache, whilch are still on it until mover runs. The disk info seems to come and go, but the cache works fine. Sorry to respond so many times but things kept chaning and throwing me off. Diagnostics in comment above. Thanks again for any insight!

Nevermind, this info is available now. I expected it to be available immediately. I'm out of SATA ports so I shut down, replaced one cache drive, rebooted, put the new drive in the empty slot, waited for the array to start and btrfs to finish its mounting, which took a bit. Then I did the same for the second drive. Then I rebooted again for good measure. Though I haven't rebooted since last time I checked. I guess it just takes some time to appear after installing a new drive... I didn't even consider it could be delayed.

Here's Diagnostics. I normally do include them, but I thought WD drives were probably common and it might just not work with them. Thanks for checking it out! megachurch-diagnostics-20221119-0512.zip

I just upgraded my cache from 2x500GB to 2x1TB with two WD Blue SSDs, mirrored. When I view the disk info, the Attributes and Capabilities tabs have 'not available' messages. I couldn't find much about it searching. One reason I replaced them as well was error messages from those attributes on my other disks, and it seems I'm blind to them now, but I wouldn't expect WD to be that rare or odd as for as drives go. I was previously using Samsung Evo SSDs, but one was getting an increasing reallocated sector count, then worse errors. I replaced it with another EVO. Same thing happening with it a few months later (the other has been perfect though), so I decided to change brands and increase the size. Now I'm worried the same thing will be going on and I won't know about it. If that's going to be the case with these drives, would it result in corrupt files potentenially being moved, or does btrfs somehow notice if something doesn't match up?

Sorry to necro a thread, but I'm still on 6.9.2 - I'm only using it as a SMB file server so it is still suiting me fine, but I do like to stay up to date. Does anyone know if extra steps are still necessary in the current version (6.11.1)? Was this ever fixed? I did attempt to update to 6.10.2 when it was new and got the message that it couldn't find ETH0 (I believe that was it), as described here and just restored my backup, figuring it would eventually be addressed.

I have the minimum free space on my array set to 150GB. This overrides any setting you have for the cache, or I would have it a bit bigger for the disks to ensure free space, and smaller for the cache. In any case, my cache min space is set even lower than that, so it isn't a factor here. When copying files to the cache, it will still have 170GB free at times when it switches to writing to the drives in the array. Why doesn't it use the last 20GB always? I'm not using anything other than the share - no VMs, Dockers, etc. On latest version of Unraid etc. Not the biggest deal, but I like to understand what's going on.

Remembering a little better now, I'd removed the share completely, as only my user share was on each of my disks. I'm not sure why the iso share reappeared then. I just noticed there was more than one folder on a disk which isn't usual. My user share should have been the only thing on the actual array. I've deleted the share again, but if it matches up with the post from 2017, it might appear again.... I shall see.

I'm not using VMs, the VM service hasn't run since I first set up my server. I have the isos share set to use the cache. However, I sometimes have an empty isos folder appear on one of my storage drives. I expect it to stay there (and empty) on my cache array, but why is it appearing on a storage drive? Under Cache, it is set to YES:Cache (not prefer). I found a thread from 2017 describing the exact same thing, but the thread ended with no real solution or explanation (just another member saying it might be a bug, but I don't think so given it has been 4 years). Anything I'm missing here, or explanation anyone can provide? It isn't really hurting anything, but I like to know why my stuff is doing what it does. Attached diagnostics megachurch-diagnostics-20210818-2334.zip

Makes sense, this is honestly my first experience with xfs on mechanical drives. After the full move of 35TB, I'll run a parity check. As long as that's good, I'm happy!