JorgeB Posted July 7, 2017 Share Posted July 7, 2017 If you rebooted since confirm that the SSD is still sdf and type on the console:xfs_admin -U generate /dev/sdf1 Link to comment
TODDLT Posted July 7, 2017 Author Share Posted July 7, 2017 5 hours ago, johnnie.black said: If you rebooted since confirm that the SSD is still sdf and type on the console: xfs_admin -U generate /dev/sdf1 See below error report Link to comment
JorgeB Posted July 7, 2017 Share Posted July 7, 2017 See if it mounts, if it doesn't you'll need to use xfx_repair with -L, to try and mount it before changing the UUID you need to do use the UD plugin with the array stopped so the other disk with the same UUID is not mounted. Link to comment
TODDLT Posted July 7, 2017 Author Share Posted July 7, 2017 5 hours ago, johnnie.black said: See if it mounts, if it doesn't you'll need to use xfx_repair with -L, to try and mount it before changing the UUID you need to do use the UD plugin with the array stopped so the other disk with the same UUID is not mounted. Please confirm these steps: Stop the array Try to mount the drive. Assuming it does mount, then go back and use the command: xfs_admin -U generate /dev/sdf1 Do I unmount the drive before using the -U generate command? If it doesn't mount, then use the command xfs_repair -L /dev/sdf1. Then do I have to go use the -U generate command over again after this? Is there a chance I could lose the contents of the drive at this point? After I get the SSD SDF to mount, then go restart the array. Link to comment
JorgeB Posted July 7, 2017 Share Posted July 7, 2017 Just now, TODDLT said: Assuming it does mount, then go back and use the command: xfs_admin -U generate /dev/sdf1 Yes, mount, unmount and run the command. 1 minute ago, TODDLT said: If it doesn't mount, then use the command xfs_repair -L /dev/sdf1. Then do I have to go use the -U generate command over again after this? Yes 1 minute ago, TODDLT said: Is there a chance I could lose the contents of the drive at this point? There's always a chance, but usually there's no data loss. 2 minutes ago, TODDLT said: After I get the SSD SDF to mount, then go restart the array. After changing the UUID. Link to comment
TODDLT Posted July 7, 2017 Author Share Posted July 7, 2017 Thanks, it will be a couple hours before I'm back in front of the machine and I'll let you know how it goes. Link to comment
TODDLT Posted July 7, 2017 Author Share Posted July 7, 2017 Separate but related topic. You said (in another thread) that you had done some testing on SSD's in an array. Did you ever do any testing with WD Blue or PNY SSD's? I still plan to get 2 ea. 120 GB drives to mirror for cache and 1 more 500 GB array drive. Link to comment
JorgeB Posted July 7, 2017 Share Posted July 7, 2017 14 minutes ago, TODDLT said: Separate but related topic. You said (in another thread) that you had done some testing on SSD's in an array. Did you ever do any testing with WD Blue or PNY SSD's? Nope. Link to comment
TODDLT Posted July 7, 2017 Author Share Posted July 7, 2017 1 minute ago, johnnie.black said: Nope. Is there any you would trust other than Samsung (high price point)? Am I overthinking this? Is this likely to be an issue and stay with the "tested" drive or as long as the drive has good product reviews I should probably be OK? (IE WD Blue, PNY, Mushkin, Crucial etc...) Link to comment
JorgeB Posted July 7, 2017 Share Posted July 7, 2017 I've used a lot of different SSDs without issues, only ones I avoid are TLC SSDs, chose one that uses MLC or 3D TLC NAND flash. Link to comment
TODDLT Posted July 7, 2017 Author Share Posted July 7, 2017 4 minutes ago, johnnie.black said: I've used a lot of different SSDs without issues, only ones I avoid are TLC SSDs, chose one that uses MLC or 3D TLC NAND flash. I'm sure I'm missing a nuance here. You said avoid TLC, but then said choose MLC or 3D TLC NAND. Should TLC not be on the "choose" list? or is there a TLC NAND that is OK? I haven't checked them all, but: Samsung seems to use 3D Vertical Muskin seems to use MLC Curcial seems to use 3D Vertical PNY seems to use TLC - So this is off the list WD Blue doesn't list this spec on NewEgg. I'll dig a little deeper on their website. Corsair Force LE 200 uses TLC - off the list Corsair Force LS - uses MLC Link to comment
JorgeB Posted July 7, 2017 Share Posted July 7, 2017 Samsung 850 EVO is 3D TLC = good, for example the cheaper 750 EVO is normal TLC = not so good. Link to comment
TODDLT Posted July 7, 2017 Author Share Posted July 7, 2017 22 minutes ago, johnnie.black said: Samsung 850 EVO is 3D TLC = good, for example the cheaper 750 EVO is normal TLC = not so good. OK, I probably need to go tot he manf website and pull their data to get the whole picture then. Newegg just calls out 3D Vert for the 850, and doesn't call out anything for the 750. So I'm looking for 3D TLC What about 3D Vertical? that was called out for Samsung 850 and Crucial MX300 series, is this the same as 3D TLC? MLC NAND Link to comment
TODDLT Posted July 7, 2017 Author Share Posted July 7, 2017 3 hours ago, johnnie.black said: Yes, mount, unmount and run the command. Yes There's always a chance, but usually there's no data loss. After changing the UUID. HEY! mounted and working now. Thanks!! I'll run the comparison and see what if anything shows up. I think I'm down to 32 "changed" files and most of those I can identify having made the changes too. I'm still not sure what caused the 5 parity check errors or caused the SSD to fail 2 days later. Thanks for sticking with me on this. Don't quite write me off as solved yet, and I will confirm back, hopefully later tonight. Link to comment
TODDLT Posted July 8, 2017 Author Share Posted July 8, 2017 Well I think this is on the right path. After doing comparisons between the backup and the HDD restored from parity, then checking between the HDD & SDD. - I've been able to get everything on the SSD that was written since the redball. Just a handful of things. - After checking all the "differences" I didn't find anything that wasn't a change that I knew I made so still unsure of the original of the parity errors, other than some cable issue, or who knows. This step was the whole point to going through all this effort. To try and make sure the parity errors were not the result of some data corruption that occurred since the last backup and had eventually cause the drive problem. At this point I think I've taken that as far as it can go. I'm going to change the way the SSD is mounted before doing a new config and re-building parity again. The change will allow the SATA cables to latch on the drive side. Running one final comparison. Unless something unexpected comes up, I'll make the mounting/cable changes tonight and then let the parity re-build overnight. I don't ever remember hearing of people having drive cable issues in a Windows box. However there seem to be a substantial number of "errors" that occur due to cabling in unRAID. That is just looking at the number of times you see the subject come in up threads and run into it a couple times of my own. More drives in a box means more opportunities for issues and I guess the parity operation and checks means the whole system is more sensitive to it. A lot more reading/writing going on. Not sure where I'm going with that but it seems to stand out to me anyway. My MB has latching SATA connectors, but they are a stacked design but they are so tight that the lower cable latch is depressed by the upper cable so only the upper latch actually stays engaged. I'd love to find a more slimly designed latching cable head.. but no idea if there is one out there that would work better than the one I have. Its just very tight and were even hard to get plugged in. As a last thought if you know of any please leave a note. Thanks again for all the help! Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.