SnapRAID: An Open Source alternative to UnRAID and FlexRAID - Page 6

I used it at the get go, when it did not work very much at all. Provided him a test bed of a system to obtain log files from, network activity, etc. I tried to break it, was successful, gave him the logs, he fixed the bug, tested the next version. On and on.

Had he said from the start "I am going to have you guys pay for this later, but you can use it for free for now as beta testers" I would have no problem with it. I beta test software quite often for the major gaming companies.

He also kept alluding to the removal of the time bomb from the betas after he finally admitted he was going to charge me for the software. The beta we good enough for my use, so I was happy. Then he decided to not remove the time bombs.


It is what it is, he wants to make money, and I can understand that. Had he been clear about it from the start it would all be fine by me. This will teach me to ever use non-GPL "free" software again.

Have you talked to him? He clearly says in the post about pricing that people that helped out like that will get it for free.

OK, so I installed SnapRAID and got a LOT of errors while running it. I used the GUI to setup and do the initial sync. It was beeping away. Here are a few sample lines.

2012-03-17 15:05:05.3022[8][] WARN Elucidate.Form1: Process StdErr[runos:13172:13173:13806152353]
2012-03-17 15:05:05.3646[8][] WARN Elucidate.Form1: Process StdErr[runos:13173:13174:13807200929]
2012-03-17 17:26:03.4563[1][] ERROR Elucidate.Program:

When I ran the check, these are the errors I received:

2012-03-17 17:26:03.5499[1][] ERROR Elucidate.Program: File Re-opened: Ver :12.1.30.258
2012-03-17 17:26:17.2312[6][] DEBUG Elucidate.Form1: actionWorker_DoWork
2012-03-17 17:26:17.2936[6][] INFO Elucidate.Form1: Using: "C:\\snapraid\\snapraid.exe"
2012-03-17 17:26:17.3092[6][] INFO Elucidate.Form1: with: -v -G -c "C:\\snapraid\\snapraid.conf" check
2012-03-17 17:26:17.3404[7][] INFO Elucidate.Form1: Start StdOut
2012-03-17 17:26:18.3388[9][] WARN Elucidate.Form1: Start StdErr
2012-03-17 17:26:18.3388[9][] WARN Elucidate.Form1: Process StdErr[selftest:]
2012-03-17 17:26:18.3544[9][] WARN Elucidate.Form1: Process StdErr[version:1.8]
2012-03-17 17:26:18.3544[9][] WARN Elucidate.Form1: Process StdErr[conf:C:\\snapraid\\snapraid.conf]
2012-03-17 17:26:18.3856[9][] WARN Elucidate.Form1: Process StdErr[blocksize:262144]
2012-03-17 17:26:18.3856[9][] WARN Elucidate.Form1: Process StdErr[disk:d0:N:/]
2012-03-17 17:26:18.4012[9][] WARN Elucidate.Form1: Process StdErr[disk:d1:O:/]
2012-03-17 17:26:18.4012[9][] WARN Elucidate.Form1: Process StdErr[disk:d2:P:/]
2012-03-17 17:26:18.4012[9][] WARN Elucidate.Form1: Process StdErr[disk:d3:Q:/]
2012-03-17 17:26:18.4168[9][] WARN Elucidate.Form1: Process StdErr[mode:raid5]
2012-03-17 17:26:18.4168[9][] WARN Elucidate.Form1: Process StdErr[parity:M:/parity/SnapRAID.parity]
2012-03-17 17:26:18.4168[9][] WARN Elucidate.Form1: Process StdErr[content:N:/SnapRAID.content]
2012-03-17 17:27:20.0101[9][] WARN Elucidate.Form1: Process StdErr[run:begin:0:6369736:0]
2012-03-17 17:27:20.2285[9][] WARN Elucidate.Form1: Process StdErr[run:end]
2012-03-17 17:27:20.4469[7][] INFO Elucidate.Form1: Process StdOut[Self test...]
2012-03-17 17:27:20.4469[4][] INFO Elucidate.Form1: Exited.
2012-03-17 17:27:20.4625[7][] INFO Elucidate.Form1: Process StdOut[Loading state from N:/SnapRAID.content...]
2012-03-17 17:27:20.4625[7][] INFO Elucidate.Form1: Process StdOut[ file 9261]
2012-03-17 17:27:20.4781[7][] INFO Elucidate.Form1: Process StdOut[ block 22030599]
2012-03-17 17:27:20.5093[7][] INFO Elucidate.Form1: Process StdOut[ symlink 0]
2012-03-17 17:27:20.5561[7][] INFO Elucidate.Form1: Process StdOut[Checking...]
2012-03-17 17:27:20.5561[7][] INFO Elucidate.Form1: Process StdOut[No error]
2012-03-17 17:27:20.5717[6][] INFO Elucidate.Form1: ExitCode=[0]
2012-03-17 17:27:20.5873[6][] INFO Elucidate.Form1: We are exiting the status thread
2012-03-17 17:27:20.6029[1][] INFO Elucidate.Form1: Completed


ANy idea what that means?

Here is my config file:

# Configuration for snapraid via Elucidate
parity M:\\parity\\SnapRAID.parity

content N:\\SnapRAID.content
content O:\\SnapRAID.content
content P:\\SnapRAID.content
content Q:\\SnapRAID.content
content M:\\parity\\SnapRAID.content

disk d0 N:\\
disk d1 O:\\
disk d2 P:\\
disk d3 Q:\\

exclude *.bak
exclude *.unrecoverable
exclude Thumbs.db
exclude \\$RECYCLE.BIN
exclude \\System Volume Information

block_size 256

I may have found my own solution...the GUI added this:

content N:\\SnapRAID.content
content O:\\SnapRAID.content
content P:\\SnapRAID.content
content Q:\\SnapRAID.content


But these drives are also my DATA drives...which is says are NOT to be used as a content list location. I will remove them from the config and try again.

Hmmm, I have never tried the GUI since the configuration file is so easy, but SnapRAID does support putting the content files on the data drives as of v1.8, and the author actually recommends it.

If I were you, I would put those lines back in (i.e., the same config file you originally posted), and try running 'snapraid sync' directly without using the GUI and see what happens.

By the way, does the folder M:\\parity\\ already exist? I don't think snapraid will create it itself (maybe the GUI will?), so if it does not exist, try creating it as an empty folder.

Hmmm...yes, the folder already exists. I tried running it with only M as the content, and it yelled at me, saying it need at least two drives. I then added E:\\ as a second content drive and it is running right now. I am getting a ton of the same errors.

Maybe I will just run it first from the cmd line and then use the gui to setup the cron job. All this beeping is bugging the crap out of me.

Here is a sample from the log:

2012-03-17 20:51:57.4377[10]WARN Elucidate.Form1: Process StdErr[scan:equal:d2:Chick Flix/How to Lose a Guy/backdrop.jpg]
2012-03-17 20:51:57.5297[10]WARN Elucidate.Form1: Process StdErr[scan:equal:d2:Chick Flix/How to Lose a Guy/folder.jpg]
2012-03-17 20:51:57.6047[10]WARN Elucidate.Form1: Process StdErr[scan:equal:d2:Chick Flix/How to Lose a Guy/mymovies.xml]
2012-03-17 20:51:57.6967[10]WARN Elucidate.Form1: Process StdErr[scan:equal:d2:Chick Flix/How to Lose a Guy/VIDEO_TS/VIDEO_TS.BUP]
2012-03-17 20:51:57.7787[10]WARN Elucidate.Form1: Process StdErr[scan:equal:d2:Chick Flix/How to Lose a Guy/VIDEO_TS/VIDEO_TS.IFO]
2012-03-17 20:51:57.8727[10]WARN Elucidate.Form1: Process StdErr[scan:equal:d2:Chick Flix/How to Lose a Guy/VIDEO_TS/VIDEO_TS.VOB]
2012-03-17 20:51:57.9647[10]WARN Elucidate.Form1: Process StdErr[scan:equal:d2:Chick Flix/How to Lose a Guy/VIDEO_TS/VTS_01_0.BUP]
2012-03-17 20:51:58.0567[10]WARN Elucidate.Form1: Process StdErr[scan:equal:d2:Chick Flix/How to Lose a Guy/VIDEO_TS/VTS_01_0.IFO]

Well, so far the command line seems to be working fine. It is doing the sync and says it has 77 mins left and is using 942M of memory. Is there any way to make it use more memory and thereby finish sooner, or is it not reallly worth it since once a sync is done, the sync's after that are all fast?
EDIT: 1 hour later and I still have 57 minutes left.

No, the limiting factor is either the read speed of your slowest data HDD, the write speed of your parity HDD, or possibly the speed of your CPU if you have a lot of fast HDDs and/or a slow CPU (computing the checksums is processor intensive). Most likely bottleneck is your slowest data HDD that is limiting the speed. If it happens to be reading a file near the hub of a HDD, that will usually be the slowest.

By the way, the initial estimate of the time is usually a bit optimistic, since it is likely that you will be reading files on the outer edges of the HDDs first, so the throughput will usually be a bit higher at the beginning, and falling off as time goes on.

Microsoft's estimates are optimistic...this one is just flat out wrong. 2.5 hours later and my 77 minuts is down to 55 minutes. I was very surprised when it gave me such a short time at the start, since FlexRAID took a great many hours.

The estimator could use quite a bit of work.

I'm not sure why it is off so much for you. Are any other programs reading your data disks? Approximately how much data is on each of your disks, and how many files?

My fileserver is running linux, and it has a mix of 2TB and 3TB HDDs, and the time estimate is only slightly off for me. The last time I rebuilt the parity from scratch, the ETA was about 8 hours at the start, and the actual time was about 9 hours.

Anyway, you can make your own estimate if you know how long it takes to read every file on each of your data disks (i.e., if you copied each of your data disks, in turn, to a fast RAID-0 from windows). The total time should be a little longer than whichever data disk takes the longest time to read every file. Unless you have a really slow parity drive, in which case the time will be limited by how long it takes to fill up your parity drive.

The GUI messes things up for me as well. I can use it, but if I go into the settings and save it, it will mess up my config file. I think it was adding the parity drive to the content list like yours. And that gave me errors.

I used it though and it worked ok. I just stay out of settings. I'm a total command prompt noob so I try to avoid it. Although I really need to learn how to use it.

The beeping is a known problem with the GUI
http://elucidate.codeplex.com/workitem/list/basic
As for the other things, then run the same command that is shown in the log to see if the problems exist (Which it looks like you have done by reading through this forum)

Why does adding the parity drive as also a content storage location, give you errors, especially when you state that you used it and it worked?

Those are not error's, It's the StdErr console output that SnapRaid is using to log information out as to what it is actually doing, if you do not want to see them, then take Verbose off the options in the settings.
Beeping is already noted: Please upvote to remind me to get it fixed sooner @ http://elucidate.codeplex.com/workitem/list/basic

I have 4 data drives and the parity drive. The parity drive is 2 TB The four data drives are:

N: 2TB
O: 2TB
P: 1.5TB
Q: 1.5TB

None are more than 80% full. All are power saving drives, either Seagate or Western Digital. My C: drive is a SSD, so maybe that is what messed it up...though that drive is not in my config at all.

Right now, 11.5 hours later (almost) my 77 minute time remaining still has 61 minutes remaining and is 15% complete at 24 MiB per sec.

EDIT: Not really copmlaining about the bad time estimate - I knew the estimate was way off. I am simply bringing it to the attention of others here so they will not be surprised if they see a very low ball estimate.

Ordinarily, something called a standard error, wrt creating parity, I would have guessed was that there was no parity info...so no big deal. It would be an expected error. But the beeping made me feel something was wrong.

I will upvote. I LOVE your GUI. It is amazing! Being new to SnapRAID, the only reason I thought the content files could not be on the data drives was from reading the start of this thread to learn more about the product...and it was in several dozen posts. I did not notice it went away with the latest version.

What's really annoying, is that I have not narrowed it down as to what part of the code "Feels" it needs to beep! otherwise I would have removed it already..
Work in progress, Thanks for the feedback, and Suggestions for improvements welcome (Over @ Elucidate)

It only worked after I fixed it. I have tried it twice. Each time it edited my config file. So I just don't do that anymore and its fine.

I think there is something wrong, and it is not (just) the time estimate. You said your data drives were less than 80% full, and they are 1.5 and 2TB. Unless you have a bunch of small files (you didn't answer my question about how many files), it should take 6 to 7 hours to read all the files on your data drives.

But if snapraid is only reading at 24 MiB/s, then that clearly indicates a problem. That number is the aggregate of all your data drives, so at best, it has completed reading all but one of the data drives and the last one is reading at 24 MiB/s, which is slow for data drive (my slowest drive reads at about 70 MiB/s at the hub position, and snapraid reports the total throughput as nearly 800 MiB/s on my system). But more likely your snapraid is still reading 2 or more drives in parallel, in which case each drive is reading at 12 MiB/s or less. That is very slow.

If you are only 15% complete after 11.5 hours, then it may take 77 hours total to finish. My system never took longer than 10 hours to do a complete parity rebuild, and that was with some 3TB HDDs.

Are all of your drives connected to motherboard SATA ports? None of them are USB drives or network drives?

Do you remember what the throughput was when snapraid first started? It should have been 200 - 300 MiB/s or more, since it would be reading four drives in parallel.

I stopped it and rebooted the machine. Windows likes to be rebooted now and again anyway to get that fresh feeling again. My drives are all eiteh DVD rips or BluRay rips...one drive has all the DVD rips and the others are all BR rips. 100 DVD rips and the rest BR - not exactlu sure how many, but they are all ISOs, so just 1 file each with 3-4 small files used by MediaBrowser.

The new time said it was 11 minutes nad is down down to 4 minutes. at 33% complete. It is now running at 245 MiB/s, much faster. Not sure what the problem was from before.

The throughput started at around 700Mi/s, which surprised me, but it read the drives very quickly (after reading the content file). It did nto stay that high very long, a few seconds, then down to the 245 I have now.

Hmmm, 245 MiB/s sounds reasonable, but obviously an ETA of 11 minutes is way off.

The initial high throughput (for a few seconds) usually comes from the RAM cache already having some data in it. For example, if I start snapraid, let it go for a minute, then stop it, delete the parity and content files, and then start it again, that forces it to read the same data again. But some of the data is still cached in RAM from the last read, so it goes very quickly for a few seconds. In your case, I'm not sure why it would have any data cached since you just rebooted, unless the HDDs somehow retained some data in their caches.

Doesn't burst speed come from the hard drive cache? I think once the cache fills up it lets it all out resulting in a burst read.

I found two issues...first is that I mistyped the numbers this time around. 7 hours, not 7 minutes. They were minutes the first time, but hours this time, and I meant to type hours, but after reading my own previous posts, typed minutes. This makes more sense.

The sync has completed, and I ran it a second time. This time is said 1 minute and it meant 1 minute.

I suspect the first time around was some Windows glitch that solved itself when I rebooted. It happens from time to time...I should have thought to reboot before saying anything - I know better!

Anyway, I am all synced and I tested the sync good by running it again and it found no changes. I then added another DVD to one drive and the sync went fast. All is well. I will have to grab a spare HDD and test a recovery to it.

I tried snapraid over the weekend and I tested it on my Ubuntu server and it currently has 2 2TB drives and 2 3TB drives plus a 3 TB drive for parity. It took about 30 hours to sync and then I did a check and after 15 or so minutes it found a couple of differences in about 5 files on three different drives. These files were all copied so I did a check and fix and it started to fix the differences. The troubling part is that it was changing my files and not the parity. I then checked the 5 files against the backups to see if they were really different and they were so it changed some bits in the perfectly good originals. Not sure what to think of this I have trouble believing that 5 files would have changed that quickly on three different drives also troubling is those files were found with only 15 minutes of checking - it had 8-9 of hours to go.

Woah! You did a sync, a check, and a fix all this weekend?

If so, I think there is both something wrong in your system, and something wrong in front of your system.

First, I am surprised it took 30 hours to sync. I have some 94% full 3TB drives in my system, and it takes about 10 hours to regenerate the parity from scratch with 'snapraid sync'. Is there something slowing down your system? If your data drives all have a significant amount of data on them, then you should be reading at around 300-400 MiB/s at the beginning. What throughput did snapraid report?

Are you certain that all of the files on your data drives were static during the sync? Any possibility that some of the files could have been getting modified by some background process during the sync?

What filesystem do you have on your parity drive?

Did the sync complete without any errors? Because it makes no sense that a check would generate errors right after a sync. The chances of random bit flips occurring within a few hours of snapraid having generated checksums on all your data is quite low. Much more likely is that some files were not static during the sync, or you have one or more bad drives, or a bad cable, or something else that caused read or write errors during the sync.

Finally, I'm not sure if you understand the purpose of 'snapraid fix'. That command is more commonly used to restore data from a failed drive, or to restore deleted files. While it can theoretically restore a file that went bad due to bit rot, it can only do that if the file was read correctly, and parity written correctly, during a previous sync. But in your case, your initial sync probably had read or write errors, so it was not a good idea to do a 'snapraid fix'.

I think the first thing you need to do is check the connections on all your HDDs -- SATA, power, HBA (if applicable). Then you could do filesystem checks (fsck), bad block scans (badblocks), and if that all looks okay, you could run md5sum on some files, then copy the files to your parity drive, and then run md5sum again to see if they were copied correctly.

Woah! When you did sync you never did a check? You knew the program would work flawlessly on your system! Wow, nothing wrong in the front of your system. To answer your questions, my drives are all formatted XFS, the sync completed with no errors, I performed the check to see if there were any unreported errors and to see if the sync really worked and then I was going to delete a file, mess up a file, etc. to see what would happen. The check start showing errors only minutes after it started I stop it after 15 minutes. I then did the check & fix to see what it would "fix" (I stopped it after 5 fixes). The program decided that some of my rips were bad across three of the drives. My files are quite static and all were backed up by duplication to my older unused drives. I compared my whole drive against the original backups and the only changed files were the ones snap raid altered.
Finally, I completely understand the purpose of snap raid - I have written a program that is very close to it but I used mysql for content/checksums/indexes and management. My computer only took a long time due to two 2 TB green drives in it that are really slow and quite full - I got around 85MB/s . The parity file was 2.5 TB. My system is used heavily for viewing movies, music, etc. seems if I was having drive read/write problems it would have been noticeable by now. Like I said, I compared the original to my backups and all was good. The only untested items in the equation are the software and my parity drive, which is new. Lastly, the software system I designed created checksums for the files used to create the parity so if a bad check occurred it could figure out what was bad - is it the original file or the parity?
I plan on doing more extensive testing on my system this weekend to make sure I don't have a problem, don't think I do but the new 3TB drive has not been throughly tested.

What are you talking about? I run a check about once a month. It is useful to find random bit flips. But so far, I haven't had any.



There is no need to run 'fix' to "see what it would fix". The 'check' command will tell you all the files with blocks that do not match the checksum data stored in the content file. Those are the files snapraid would attempt to fix if you ran 'snapraid fix'.

And no, the program did NOT "decide that some of your rips were bad". snapraid has no way to tell whether your "rips were bad". All snapraid can do is to compare the checksums in a previously saved content file to the checksums computed for the files when 'snapraid check' (or 'fix') is run.

In your case, it is very likely that the checksums saved in one or more of the content files (you could test whether the content files are identical with md5sum) were incorrect, either due to some files changing during the initial 'sync', or to a read error when snapraid was computing the checksums (during 'sync'), or due to a write error in the content file(s). It is unlikely that your stored data had random bit flips during the ~30 hours between when snapraid initially computed the checksums and when you ran 'snapraid check'.

Did you run the snapraid verification program after you compiled it? ('make check')

Yes I ran make check and no errors. In the manual its said run check if you are paranoid and you need to verify that all is ok, is exactly what I did. It seems strange to me that checksums would be incorrect on different files across different drives, yet my off-line backups going back over a couple of years show no errors on any of the thousands of files using cmp. I am glad the program is working for you and I appreciate the developer effort as well as putting the source code out - maybe if I've got time I'll see if I can hunt down the source of this bug. I was just sounding a warning that there maybe problems.

Your mistake was not running 'snapraid check', your mistake was running 'snapraid fix'. That makes no sense, because it is very unlikely that you got multiple random bit flips between the time snapraid read your data and computed the checksums, and the time you ran 'snapraid check'. As I have already said twice, most likely is that you have one or more bad drives, or else some of your files changed during the initial sync.

As for comparing your files to your backups using cmp, did you specifically verify the five files you mentioned that 'snapraid check' indicated had errors? If you did, and the files were identical with your backups, why did you run 'snapraid fix'?

After running sync with NO errors, I ran snapraid check and after 15 minutes I saw 5 different files pop-up with byte differences I stopped the check at that point. I then cmp the "bad files" against the original files (they were the same) then I started snapraid fix, to see what it fixed (I thought it would be the raid file). I stopped it after the fifth file and rechecked with cmp and found it "fixed" those 5 files that were not broken. I've subsequently checked the other files against my off-line backups and there are no other errors. Sorry I did not make this more clear.
I've created a mock-up of the "make check" test to run on the drives in question and it passed - albeit it was a LOT smaller test. I've git the 1.9 version that the developer committed and will test it on the same drives with a big files over the next day or two when my server has a little spare cpu time.