thegizzard

For some reason the "rebuild" slowed to a crawl overnight. See attached. Would I do any harm if I stopped the array and put the suspect disk back? Either by putting it back in its original slot 8 or simply by expanding the array? My original intention was to copy the contents of the suspect disk (sdj) to the replacement disk (now disk 8). Given this really slow rebuild, I wonder if I am better off losing parity (there is none currently) and starting over with the suspect disk back in the array. BTW.. the disk is only suspect because of 4 reported uncorrect see below. # Attribute Name Flag Value Worst Threshold Type Updated Failed Raw Value 1 Raw read error rate 0x000f 118 099 006 Pre-fail Always Never 168246480 3 Spin up time 0x0003 090 090 000 Pre-fail Always Never 0 4 Start stop count 0x0032 100 100 020 Old age Always Never 13 5 Reallocated sector count 0x0033 100 100 010 Pre-fail Always Never 0 7 Seek error rate 0x000f 078 060 030 Pre-fail Always Never 64769624 9 Power on hours 0x0032 097 097 000 Old age Always Never 3236 (4m, 11d, 20h) 10 Spin retry count 0x0013 100 100 097 Pre-fail Always Never 0 12 Power cycle count 0x0032 100 100 020 Old age Always Never 9 183 Runtime bad block 0x0032 100 100 000 Old age Always Never 0 184 End-to-end error 0x0032 100 100 099 Old age Always Never 0 187 Reported uncorrect 0x0032 096 096 000 Old age Always Never 4 188 Command timeout 0x0032 100 100 000 Old age Always Never 0 189 High fly writes 0x003a 100 100 000 Old age Always Never 0 190 Airflow temperature cel 0x0022 078 064 045 Old age Always Never 22 (min/max 22/33) 191 G-sense error rate 0x0032 100 100 000 Old age Always Never 0 192 Power-off retract count 0x0032 097 097 000 Old age Always Never 6763 193 Load cycle count 0x0032 094 094 000 Old age Always Never 13915 194 Temperature celsius 0x0022 022 040 000 Old age Always Never 22 (0 9 0 0 0) 195 Hardware ECC recovered 0x001a 118 099 000 Old age Always Never 168246480 197 Current pending sector 0x0012 100 100 000 Old age Always Never 0 198 Offline uncorrectable 0x0010 100 100 000 Old age Offline Never 0 199 UDMA CRC error count 0x003e 200 200 000 Old age Always Never 0 240 Head flying hours 0x0000 100 253 000 Old age Offline Never 1753 (251 22 0) 241 Total lbas written 0x0000 100 253 000 Old age Offline Never 50278949009 242 Total lbas read 0x0000 100 253 000 Old age Offline Never 157753475851

Yep. I definitely screwed up. When it first started the rebuild, the drive said unmountable. For some reason I thought that meant I should format it. Anyway. Fortunately the suspect drive is in tact, I will copy it to the array when the parity build it done.

Ok. thats what I wanted to happen. But is it normal for the files that were on the suspect disk to be missing from the array? I would have expected them to be emulated. Also disk 8 is not increasing ion size. Is that normal?

I thought I could unassign a drive then assign a new (precleared) drive in its place and then unraid would rebuild parity and copy the contents of the formerly suspect drive to the new drive. It's rebuilding parity but I dont think its adding any new files to the new drive. Did I misunderstand this? I am not worried about losing data. I have the suspect drive in unassigned devices and if necessary I can rsync the data to the new drive. I just want to better understand what the parity sync/data rebuild it currently doing. Should I let it finish or should I just start an rsync to copy the data from sdj to disk 8?

Fwiw.. here is the thread where Johnny black put me on track for my cache upgrade. https://forums.lime-technology.com/index.php?/topic/55089-Migrate-Cache-disk-spinner-to-SSD Sent from my SM-N920V using Tapatalk

Did you follow the cache drive upgrade process in the FAQs. I just did this and it was a breeze. Sent from my SM-N920V using Tapatalk

Haha. Thanks Johnnie. Clearly I need an extra cup of coffee. It's all finished and everything is up and running with the new SSD. Thanks much!!

Ok. I ran the btrfs start command and the prompt came right back. I thought it wasn't working but top shows btrfs is doing something. If that's expected it might be worth adding to the FAQ that this part will take a while. I'm letting it run now. Thanks for your help. I will report back. Sent from my SM-N920V using Tapatalk

I was able to resize the cache (sdk) to 894gb to match the SSD. I followed the steps to clear the FS on the SSD (sdl). I am unsure of how to start the cache replace. I think I need to add the ssd to the cache pool, but I am unsure. Can you confirm what I do next? Attached my main screen.

Thanks! I'll check it all out when I get home. Sent from my SM-N920V using Tapatalk

Cool. One question. My current cache is a pretty slow 1TB drive. I am replacing with a 960GB SSD. So my replacement is smaller. Will the BTRFS replace cache procedure work in this case?

Btrfs Sent from my SM-N920V using Tapatalk

Can anyone comment on how much resources zoneminder takes up in your unraid server? I am trying to decide on whether to buy an NVR, or just use the zoneminder container. The main use of unraid is serving up Plex streams in my home so I am worried about CPU usage. Sent from my SM-N920V using Tapatalk

Is there a recommended way to do this without losing Dockers and their settings? Sent from my SM-N920V using Tapatalk

Agreed. I have a new archive disk on the way. When it arrives I will pre-clear it. If it clears, I will replace this disk 8 and send it out for replacement since its still under warranty. LBA = 0x0fffffff doesn't looks like a valid sector and since there are no pending sectors it's probably not bad sectors, but it's a disk issue, I would give it a second chance but not a third, if errors re-occur I would consider replacing it.

I stopped the rebuild. repaired xfs and started the rebuild. does it look normal now?

Hi all. Some funky stuff happened last night and my disk 8 reported 4 errors. I noticed it was unmountable. I am not sure I went about things in the correct order but it's now rebuilding but the FS is unmountable. It should be XFS. Is this normal?

I agree. And I am sure it will be good for business. Anyone who asks me about backup/raid solutions I tell about UNRAID and they are blown away. Such a superior product. More advertising will help get the word out.

You apparently haven't read about the mitigations Seagate has incorporated into these drives to offset the potential issues with shingled technology. These are outlined in some detail in the 2nd post in this thread -- the most relevant fact vis-à-vis typical UnRAID usage is "... If you're writing a large amount of sequential data, you'll end up with very little use of the persistent cache, since the drives will recognize that you're writing all of the sectors in each of the shingled zones. There may be a few cases where this isn't true - but those will be written to the persistent cache, and it's unlikely you'll ever fill it." So the performance "wall" you'll hit with shingled drives simply isn't likely with typical UnRAID usage. Note that both danioj and ashman70 have VERY large arrays and have been using these drives for well over a year and had NO issues with them. There are many other users who have had similar experiences -- and virtually NO reports of any significant write performance issues. Correct => this is the performance "wall" I referred to. But the simple fact is that actual users of UnRAID who are using these drives have NOT found this to be an issue. Remember that most UnRAID users write a lot of LARGE media files ... and these files simply won't be using the persistent cache, but will be written directly to the shingled area, so there's no performance "hit" with these files. Agree -- and if these were priced the same as PMR drives, I'd definitely recommend using the non-shingled units. But many folks are price sensitive -- and at $233.88 for an 8TB Seagate Archive drive vs. $310.97 for an 8TB WD Red drive (current Amazon prices for both) it can make a significant difference in the cost of populating an array => e.g. $770 difference if you're buying 10 drives. ... and of course there's NO difference in read performance. I don't know how you guys use unRAID, but I move all my files at night via SynchBackPro. While write speed is important, read speed is actually more important to me in my use. And I have 20TB+ on unRAID. Sent from my SM-N920V using Tapatalk

Is your point that it would be unacceptably slow? The purpose of this thread is to document how this setup performs in actual practice. I have two in my unRAID and have no performance difference vs. the NAS drives I have been running for years. If there were actual performance issues I would expect to read about them right here. Sent from my SM-N920V using Tapatalk

Just added my second 8tb shingle. PRECLEAR flawless, operating perfectly. Sent from my SM-N920V using Tapatalk

I am happy with my 8tb shingle. I meant to say PRECLEAR killed my first 8tb drive. I DOA'd it then the replacement worked fine. I've only had it for a month tho. Sent from my SM-N920V using Tapatalk

Parity check killed my first drive. The second was fine. Sent from my SM-N920V using Tapatalk

I saw a review that suggested that these were not durable for 24/7 nas use. Does anyone think these won't last in unRAID as parity and/or data disks? Sent from my SM-N920V using Tapatalk

Yep. Some files have that. Not ur fault. Sent from my SM-N920V using Tapatalk