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!

This is my first fill, migrating from an older storage system. I have two 500GB SSDs that will be my cache once it is operating normally, but I'm moving more than 500GB at a time right now. I'm using "turbo write" aka Reconstruct Write. Just for my first fill to speed things up. Otherwise I only write at about 65MB/s, which I've found in other discussions is quite normal with parity in place and no cache. I'm sure you understand it all, but this is how I understand it to work. Normally it would keep other drives spun down, read the parity info, adjust it for your new data, and re-write it, meaning the parity gets read and re-written on each write, slowing down a mechanical drive a good bit. With Reconstruct Write, it reads from all drives to form the parity data, while only writing to the parity drive. So faster, but more drives taking wear (but the parity drives taking a bit less wear as they are only writing). It makes sense that one 16TB drive has more data than the other as it has been part of the array longer. What's weird is that when reconstruct write is writing in the 10-16TB range, it of course doesn't spin up the 10TB drives as there's nothing in that range to read - however, even though I'm putting my initial files on the new 16TB, some files spin up all drives when being written, meaning they are being placed in the 0-10TB area of the drive, but others only spin up the 16TB drives, meaning they are writing to the 10-16TB area, and there's nothing parity needs from the 10TB drives in that range. However since that new 16TB drive only has 2TB on it, why are the files randomly going back and forth as far as what area of the hard drive they are being written to? One will spin up all drives, the next will only spin up the 16TB ones, then the next might spin up all. It definitely doesn't appear to be placing the files all in a row on the new disk, even though I'm copying them to the array over network one at a time, single-file. Yes, my Network is just gigabit, so it limits me to around 115MB/sec on average. I am using a very entry level system, but it's all plenty for me, especially once the cache is in place, and I'll disable reconstruct write. I won't care that it takes a bit to move the cache over while I'm sleeping. I won't be moving more files than my cache holds very often, and gigabit is more than enough for me currently. I'm mainly trying to protect a large amount of data that was once on a Drobo. I'm definitely getting faster speeds than the Drobo would sometimes give me over USB 3, dropping to 5-10MB/sec at times (even with different drives and a different Drobo). It also gives you no visibility to its content, you just trust it and its redundancy, but your drives are useless without a Drobo to read them. My extended protection on my Drobo is about to run up, and they haven't made consumer models in a couple years (no announcement but they've been out of stock). Unraid is working out a lot better for me, and I'm happy with the setup I have for now. I'm only using it for NAS for my personal stuff currently and I'm loving it. I just wanted to do anything I can to help keep it healthy, including any defragmentation I should be doing. Most of this data is seldom accessed, but the collection of data is accessed pretty often for a couple things at a time.

I'm not sure what fill rate is exactly, and searching didn't help - not sure if you mean the speed I'm filling them, how full they are, or their max write speed (or maybe something else). Pardon my ignorance on that. If this helps - one 16TB has 12.7GB, the other has 2TB and is filling up more currently. The 10's each have 4TB free, as that was the last high water mark when it was just the three drives. I am using the 'turbo write' just until I get all my data transferred as I have a lot and it's much slower otherwise. I write anywhere from 90-110MB/s over the network. When it is doing stuff to the drives directly like clearing, they get around 240MB/s. I'm not sure for the parity - they are always full, and keep up the speed of the others. I have cache drives, but they won't be added to the array until my data migration is done. The part about the numbers being unreliable makes sense - is there a reliable way to get fragmentation stats on an XFS drive? Seems like someone would have come up with a way by now...

What I don't understand, is why I have 5-8% file fragmentation on my drives, when I'm doing nothing but migrating the initial data to the drives. This isn't folder fragmentation, but files. Normally when you copy files to a fresh drive, they'd be written sequentially. I can tell it isn't writing from beginning to end in any case. I'm using 'turbo write' which means it is reading from all drives except the one it's writing to. I just put in a new 16TB (same size as my parity drives) and I notice that it varies from file to file whether it is reading from my 10TB drives, which means some files are being placed in the last 6TB of the 16TB drive, where there would be nothing to read from the 10TB ones, but other files are spinning up all discs. Why does it seem to scatter the files around, and get some fragmentation on initial copy (copying via network)?