April 6, 201412 yr I've been in the process of upgrading some hard drives and have been replacing 2TB drives with 4TB drives. Rather than a rebuild I've been adding the 4TB drives to the array and using MC to move data. Having completed this a few days ago I wanted to remove 3 2TB drives, so did a new config, reassigned the 3TB/4TB drives and then let parity build, which completed yesterday morning. Last night before I went to bed I kicked off a parity check to make sure parity was valid, however when I saw the results today I saw this: Last checked on Sun Apr 6 12:39:18 2014 EDT (today), finding 2319 errors. > Duration: 12 hours, 55 minutes, 40 seconds. Average speed: 86.0 MB/sec Other than 3-4 shows that SAB would have added to my TV folder there was nothing done other than viewing yesterday in-between the parity build and parity check, which leaves me with the question of why would there be so many errors found in parity? So, I have a couple of questions: 1) Why would so many errors be found? 2) Should this be a cause for concern? 3) Are the 2319 errors/updates done on the parity drive itself based on the reread of the data, or are these updates done against my actual data (I am assuming the first is accurate, but have never really verified). syslog.txt
April 6, 201412 yr If your unRAID is still running, attach a full syslog. If you've restarted it, attach the current full syslog. http://lime-technology.com/forum/index.php?topic=9880.0 Without the logs, you'll get some general ideas, but with the logs, specific errors (and corrections) might be spotted.
April 6, 201412 yr Author If your unRAID is still running, attach a full syslog. If you've restarted it, attach the current full syslog. http://lime-technology.com/forum/index.php?topic=9880.0 Without the logs, you'll get some general ideas, but with the logs, specific errors (and corrections) might be spotted. Thanks, I forgot to do that. I've updated my original post with the syslog (I've not rebooted since I brought up the system to do the original parity build (I think), so it hopefully has some good info).
April 6, 201412 yr Unless this is a re-occurrence of an old error from v4.7 which could cause data corruption when writes were done during initial parity syncs, I suspect these were actual errors on the parity disc, which is almost always the cause of sync errors ... so as long as you did a correcting check, everything should be fine now. If you have checksums and/or backups of your data, you can confirm that by validating your data, but otherwise there's little you can do except assume the errors are on the parity drive. This is one reason I'm such a big proponent of maintaining current backups ... although I realize many don't consider their data worth the bother [My view is simple: if you don't want to lose your data, back it up; if you don't mind losing it, then there's no need].
April 6, 201412 yr Author Unless this is a re-occurrence of an old error from v4.7 which could cause data corruption when writes were done during initial parity syncs, I suspect these were actual errors on the parity disc, which is almost always the cause of sync errors ... so as long as you did a correcting check, everything should be fine now. If you have checksums and/or backups of your data, you can confirm that by validating your data, but otherwise there's little you can do except assume the errors are on the parity drive. This is one reason I'm such a big proponent of maintaining current backups ... although I realize many don't consider their data worth the bother [My view is simple: if you don't want to lose your data, back it up; if you don't mind losing it, then there's no need]. I don't have backups or parity checks of the data at this point (though I understand your point). The issue for me now is it would have been reasonable upfront, but building another server now with 26TB of storage is a hefty investment that I really can't afford right now. It's in the back of the mind as an ultimate solution, but for now I have to live on the edge a bit. I am going to run another parity check tonight and see what the results are. Hopefully this one is now clean and life is all good.
April 6, 201412 yr FWIW, I DO have both checksums and a complete backup (of over 50TB) ... and EVERY time I've had a parity sync error, I've confirmed they were indeed on the parity disk ==> so statistically it's pretty likely your errors were on the parity disk, and all is well. I NEVER run non-correcting checks ... although others on this forum disagree with doing that, as they want to have some opportunity to try and recover their data in those rare cases where the errors aren't on the parity disk. I'm of the old school mindset that if your data is important to you, back it up !! I agree that if you've ignored doing this for 26TB worth of data, it's a bit pricey to "catch up" all at once -- 7 5TB drives would cost ~ $1200 (You don't need another server, just an external dock ... although clearly a server is more convenient). MUCH less noticeable if you simply backup as your collection grows !!
April 6, 201412 yr Author Agreed. It's one of those 20/20 hindsight type things. I've yet to see 5TB drives on sale yet, so if I am doing UnRAID I need 7x4TB for data and 1 for parity (assuming a new UnRAID server), so am closer to $1,800 plus the computer (which I'd have most of already). Definitely a bit of a heart attack - though losing some of the smaller data like family pictures would be worse.
April 6, 201412 yr Definitely a bit of a heart attack - though losing some of the smaller data like family pictures would be worse. Surely you have backups of the family pictures, etc. !! A single 4TB external drive for $150 would do nicely for the really critical stuff
April 6, 201412 yr Author Definitely a bit of a heart attack - though losing some of the smaller data like family pictures would be worse. Surely you have backups of the family pictures, etc. !! A single 4TB external drive for $150 would do nicely for the really critical stuff Yes, I have backups of the critical stuff like that. It's the multi-TB TV/Movies shares that I'd lose (and the TV shows are a bigger pain the ass than the movies at this point).
April 6, 201412 yr If your unRAID is still running, attach a full syslog. If you've restarted it, attach the current full syslog. http://lime-technology.com/forum/index.php?topic=9880.0 Without the logs, you'll get some general ideas, but with the logs, specific errors (and corrections) might be spotted. Thanks, I forgot to do that. I've updated my original post with the syslog (I've not rebooted since I brought up the system to do the original parity build (I think), so it hopefully has some good info). bkastner - Are you running 64-bit beta. This is not random parity errors sprinkled across the disk - there are a large number of sequential parity blocks that didn't verify. Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646722888 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646722896 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646722904 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646722912 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646722920 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646722928 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646722936 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646722944 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646722952 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646722960 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646722968 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646722976 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646722984 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646722992 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723000 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723008 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723016 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723024 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723032 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723040 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723048 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723056 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723064 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723072 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723080 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723088 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723096 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723104 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723112 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723120 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723128 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723136 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723144 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723152 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723160 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723168 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723176 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723184 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723192 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723200 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723208 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723216 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723224 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723232 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723240 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723248 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723256 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723264 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723272 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723280 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723288 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723296 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723304 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723312 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723320 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723328 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723336 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723344 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723352 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723360 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723368 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723376 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723384 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723392 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723400 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723408 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723416 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723424 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723432 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723440 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723448 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723456 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723464 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723472 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723480 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723488 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723496 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723504 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723512 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723520 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723528 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723536 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723544 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723552 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723560 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723568 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723576 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723584 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723592 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723600 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723608 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723616 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723624 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723632 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723640 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723648 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723656 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723664 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723672 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, sector=4646723680 Apr 6 06:38:21 CydStorage kernel: md: correcting parity, stopped logging It only logs for a while and then stops. It almost looks like you computed parity with one drive, then copied something to it, and then checked parity with the old drive Can you recount the EXACT series of steps you took. I would check the most recently copied data to the server and see if it looks ok (play a movie, for example). MD5 is nice but not the only way to verify data is good. This may be a bug and we may need to involve Tom, but let's take it one step at a time. Update - if my math is right this error is occuring just over the 2.2T boundary. Did you copy a significant amount of extra data to one of the new 4T drives after copy relicated from the smaller disks? Did you do any experiments with the trust parity procedure (set invalidslot ...)?
April 7, 201412 yr Author bkastner - Are you running 64-bit beta. This is not random parity errors sprinkled across the disk - there are a large number of sequential parity blocks that didn't verify. It only logs for a while and then stops. It almost looks like you computed parity with one drive, then copied something to it, and then checked parity with the old drive Can you recount the EXACT series of steps you took. I would check the most recently copied data to the server and see if it looks ok (play a movie, for example). MD5 is nice but not the only way to verify data is good. This may be a bug and we may need to involve Tom, but let's take it one step at a time. Update - if my math is right this error is occuring just over the 2.2T boundary. Did you copy a significant amount of extra data to one of the new 4T drives after copy relicated from the smaller disks? Did you do any experiments with the trust parity procedure (set invalidslot ...)? Yes, I am 6.0-beta4. I haven't done any serious since I reported my last preclear results to you and the other forum on 6.0 not getting the drive marked as cleared. Friday I stopped the array, ran new config and re-setup all my 3TB/4TB disks, only keeping my parity drive the same. I was doing this to remove 3 2TB drives that were part of my array (but had been emptied by MC). I brought the array up and it started parity build, but it killed my entire machine. I ended up rebooting as the GUI and shares were inaccessible, and after restart I killed the parity build until I went to bed Friday night, when I restarted it. By Saturday morning it was done the parity build and the only activities would have been SAB/SB and they only updated a few shows during the day (looking at SAB it looks like 2 shows were updated). Saturday night I ran a parity check, and it finished this morning (actually just after noon as all the parity corrections slowed it down quite a bit). I am going to assume that the new shows would have written to one of the new 4TB drives as they have the most free space at the moment, but as mentioned, it should have been minimal data write in-between parity build and parity check.
April 7, 201412 yr When the unRAID gods go bump in the night it gets our attention, doesn't it? I would say that 2319 represents only a small amount of data. My bet is that the data copied properly to the RFS disk and that once your parity is corrected you will be good to go. Have you identified any lost or missing data?
April 7, 201412 yr Author When the unRAID gods go bump in the night it gets our attention, doesn't it? I would say that 2319 represents only a small amount of data. My bet is that the data copied properly to the RFS disk and that once your parity is corrected you will be good to go. Have you identified any lost or missing data? Yup, you never like to see the unexpected with UnRAID. I just did a quick scan through the shows I grabbed Saturday, and the one show that was downloaded while the parity check was happening - all seem fine. I didn't originally realize that a show was grabbed and moved to the array during the parity check. Could it possibly have been a freak coincidence where it was checking the same spot that was being written to? Not sure how that would work, but I have to assume it would be a pretty big coincidence. Either way I am going to rerun a parity check tonight and hopefully all is good.
April 7, 201412 yr You said your machine crashed. More likely happened then. Parity is protected at a low level. You can safely use the array during a build.
April 7, 201412 yr Author You said your machine crashed. More likely happened then. Parity is protected at a low level. You can safely use the array during a build. Even though I have a pretty beefy UnRAID system I have had issues where things like Parity build/check will bring it to it's knees. I am not sure why. When I started the parity build on Friday it was 4 or 5pm which is prime time, so I rebooted the server since I couldn't access the GUI to kill the parity build. Then when it started up and tried to start the parity build again I stopped the process until late that night. I had similar issues on my old cpu/motherboard as well, but that was running 5.0 with plugins. I sort of expected the issue to disappear with a clean 6.0 install with a VM for plugins, but I've still seen parity checks/build drag a system to unresponsiveness. It's frustrating, but I don't know the cause.
April 7, 201412 yr I've still seen parity checks/build drag a system to unresponsiveness. It's frustrating, but I don't know the cause. It's actually very simple -- using the system during a parity check causes significant thrashing of the disks (some purists will note that technically it's not "thrashing", since the system is still working -- but in any event, it's causing a LOT of head movement when you access the array ... especially if you're doing writes). Consider: A parity check is accessing EVERY disk sequentially ... so the heads are "smoothly" moving in from the outer cylinder towards the inner cylinders on all drives. Now you start a write, which requires four I/O operations on at least two disks (parity plus the disk being written to). On each of these disks, the heads have to move to the first cylinder it needs to read from; then do some calculations; and then it's got to write the sector back that it just read -- meanwhile, in between those two operations, the head likely moved back to the next parity check cylinder to do another read. And this happens constantly for every sector it's writing. If you're streaming a movie (or other media), then on the disk it's streaming from, it's constantly "thrashing" back-and-forth between the next sector it needs to stream and the next sector it needs to read for the parity check. Note also that since this disk is therefore running much slower than it otherwise could, it will cause the overall parity check to run much slower. You can see a very good example of the impact of this if you have Cache_Dirs installed and automatically running. When you first boot a system, cache_dirs reads all of the directories on your disks to fill the cache. You normally don't notice the impact of this ... but there's a simple way to show it. Boot your system and IMMEDIATELY start a parity check [if you want to be sure it's started immediately, you could force an "unclean" shutdown by simply holding in the power switch to turn it off ... then UnRAID will start the parity check on the next boot.] Notice the speed of the parity check ... it will be MUCH slower than you're probably used to. Stop the check ... and wait ~ 10 minutes or so [You can clear the stats; then refresh a few times to ensure the reads stay at 0's -- when that happens cache_dirs is done]. Start a parity check again and it'll be MUCH faster ... probably like you were expecting. The impact of all this is even worse if multiple computers or devices are using the server at the same time. It shouldn't be completely "unresponsive" ... but it can certainly be SLOW. In general, it's still plenty fast enough to stream a movie, so you may not even notice it in normal use. But if you're actively using it, you'll certainly notice the difference. Bottom line: Parity checks, parity syncs, and drive rebuilds are best done at times when the server isn't going to be used for anything else
April 7, 201412 yr Author I completely agree Gary, and usually try and schedule intensive tasks during night hours when possible. I also appreciate the load you are putting the system under during a parity check/build and do expect the system to be sluggish, but as mentioned I've gotten to the point where I can't access the GUI and the system is pretty much unresponsive (I can still do things in a telnet session but that's about it). The shares are completely inaccessible as well. This is beyond what I would expect, and what causes me the head scratching. This is the type of scenario where an overall better understanding of Linux would likely be beneficial so that I could better understand what is happening. I suppose if I was smart I should have captured the logs as well before rebooting the system to see if there were any flags. At the time I was just annoyed and wanted to get it back up so my 4 year old could watch the Pirate Fairy for the bazillionth time this week.
April 7, 201412 yr You're right -- it should NOT be completely unresponsive. As I noted above, it will understandably get SLOW ... but shouldn't be so slow that your 4-year old would notice any difference in the playback of Pirate Fairy I don't bother with BluRay's, but streaming a DVD is NOT an issue during a parity check. I don't know if a BluRay stream would be an issue or not, but I suspect not. I have, however, found that the Web GUI is sometimes VERY slow during parity checks -- sometimes to the point I'd call it "unresponsive." But in those cases, I've noticed that if you click the "X" at the top of IE to stop the load; then click on the little arrow to reload the page, I've found that it usually loads right away.
April 7, 201412 yr Author You're right -- it should NOT be completely unresponsive. As I noted above, it will understandably get SLOW ... but shouldn't be so slow that your 4-year old would notice any difference in the playback of Pirate Fairy I don't bother with BluRay's, but streaming a DVD is NOT an issue during a parity check. I don't know if a BluRay stream would be an issue or not, but I suspect not. I have, however, found that the Web GUI is sometimes VERY slow during parity checks -- sometimes to the point I'd call it "unresponsive." But in those cases, I've noticed that if you click the "X" at the top of IE to stop the load; then click on the little arrow to reload the page, I've found that it usually loads right away. I've had GUI issues with IE in general periodically (which I posted in the beta4 forum), but when I was having this issue (and in the past), no matter how many times I try and reload the GUI it fails. I can completely close all IE pages and retry, and have even tried under Private Browsing, and there is no response. My general GUI issues get resolved by this means, but not during the parity build. All my media is in MKV format (well 99% is), but as mentioned I couldn't even access any of my shares. Windows Explorer sat for a long time and never came back with anything. I was also rebuilding an OpenELEC client with Gotham beta 3 and couldn't add the NFS shares (it just hung once I tried clicking on the share name). I know I could likely have waited the 10-12 hours for the parity build to complete, but it was worth the risk at the moment to reboot and kick off the movie without parity being built.
April 7, 201412 yr I noticed an oddity in your syslog: a couple of your 4TB drives are slightly smaller than the other two. Have these drives been connected to a gigabyte motherboard? You might have an HPA on these disks. I don't see how this could be related to your parity check issue, but you might want to check it out.
April 7, 201412 yr Author I noticed an oddity in your syslog: a couple of your 4TB drives are slightly smaller than the other two. Have these drives been connected to a gigabyte motherboard? You might have an HPA on these disks. I don't see how this could be related to your parity check issue, but you might want to check it out. Nope, they should all be the same, and I've only had them hooked up to an ASUS motherboard. The 4TB parity drive and one data drive I bought as internal drives, and the other two were My Book Essentials drives, but they are still all EZRX drives, so that shouldn't matter. the only other difference would have been 2 of the data drives were precleared with JoeL's v13 script, and one with BJP's 15b script, but again, I wouldn't expect that to be any difference. I completed another parity check last night, and it completed successfully with zero errors. I still don't understand what happened, but everything seems smooth now and I just have to hope the corrections were on the parity disk and not the data.
April 7, 201412 yr everything seems smooth now and I just have to hope the corrections were on the parity disk and not the data. That's almost certainly the case; but if you want to be able to confirm that in the future, then unless you're going to create a set of backups (a good idea, but many don't seem to bother), then you should at least create checksums for your files ... then you'll have a way to KNOW if a file has been modified/corrupted.
April 7, 201412 yr Author everything seems smooth now and I just have to hope the corrections were on the parity disk and not the data. That's almost certainly the case; but if you want to be able to confirm that in the future, then unless you're going to create a set of backups (a good idea, but many don't seem to bother), then you should at least create checksums for your files ... then you'll have a way to KNOW if a file has been modified/corrupted. Yes, this is a good idea and something I think I will do short term just for the extra bit of piece of mind.
April 7, 201412 yr everything seems smooth now and I just have to hope the corrections were on the parity disk and not the data. That's almost certainly the case; but if you want to be able to confirm that in the future, then unless you're going to create a set of backups (a good idea, but many don't seem to bother), then you should at least create checksums for your files ... then you'll have a way to KNOW if a file has been modified/corrupted. Yes, this is a good idea and something I think I will do short term just for the extra bit of piece of mind. Here is a script that might help that out that runs on unRAID: http://lime-technology.com/forum/index.php?topic=28168.msg255931#msg255931
April 7, 201412 yr Author everything seems smooth now and I just have to hope the corrections were on the parity disk and not the data. That's almost certainly the case; but if you want to be able to confirm that in the future, then unless you're going to create a set of backups (a good idea, but many don't seem to bother), then you should at least create checksums for your files ... then you'll have a way to KNOW if a file has been modified/corrupted. Yes, this is a good idea and something I think I will do short term just for the extra bit of piece of mind. Here is a script that might help that out that runs on unRAID: http://lime-technology.com/forum/index.php?topic=28168.msg255931#msg255931 Thanks
Archived
This topic is now archived and is closed to further replies.