Stress-testing new drives: Where are the results?

[Z300M]

I started jgrego's solnet-array-test-v2.sh on my new 6TB Seagates, and the last output I saw on the screen was that it was starting the parallel array read which was estimated to take 454 minutes. There was no new report when I went to bed (probably not much later than that 454 minutes), and when I got up this morning there was just a command-line prompt. Should this script have saved a log somewhere? I can't find one.

The Reporting tab in the GUI shows heavy drive activity for a further couple of hours after I went to bed, but looking at other users' reports, it seems that the script should have kept working these drives for a lot longer. Any way of finding out what happened? If it simply aborted, why?

 

[Bidule0hm]

If you read the script's source you should see what he's doing and where the results goes.

 

[Z300M]

If you read the script's source you should see what he's doing and where the results goes.

OK, Thanks. I had searched for *.log files without success.

Now I've found in /tmp/ files with names such as cat.daX.out (all zero-length), cat.daX.pspeed.out, cat.daX.sspeed.out, cat.daX.size.out, and (with the latest time stamps) cat.daX.err containing data such as:

Code:

5723166+1 records in
5723166+1 records out
6001175126016 bytes transferred in 34711.271964 secs (172888367 bytes/sec)

Nothing there that seems out of place to me.

I can't see anything that would explain why the test would have aborted.

 

[Bidule0hm]

Maybe the test was aborted during the night automated maintenance things (at about 3 am IIRC).

Try to launch it during the day and keep an eye on it ;)

 

[Z300M]

Maybe the test was aborted during the night automated maintenance things (at about 3 am IIRC).

Try to launch it during the day and keep an eye on it ;)

Now I'm getting error messages -- errors apparently in the script itself, but the test seems to be continuing for now: it's started the parallel array read phase. BUT all the /tmp/sat.daX.out and /tmp/sat.daX.err files are zero length; am I going to end up with any saved results to review?

 

[Bidule0hm]

Well, there's maybe some errors due to the copy-paste. What I recommend if you copy from the forum is to first copy the script's source to a simple text editor on your PC (like Notepad for example), check everything is ok (especially that the long lines are not broken) and then copy it from this text editor to the NAS (SSH with PuTTY and nano works great for me). The purpose of that is to make sure everything is ok and to avoid special non-displayable characters (due to the forum's formatting, page layout, ...), I've seen very weird problems when copy-pasting from the forum (that's why I use pastebin now)

 

[Z300M]

Well, there's maybe some errors due to the copy-paste. What I recommend if you copy from the forum is to first copy the script's source to a simple text editor on your PC (like Notepad for example), check everything is ok (especially that the long lines are not broken) and then copy it from this text editor to the NAS (SSH with PuTTY and nano works great for me). The purpose of that is to make sure everything is ok and to avoid special non-displayable characters (due to the forum's formatting, page layout, ...), I've seen very weird problems when copy-pasting from the forum (that's why I use pastebin now)

I think I did use pastebin: it's been a while. Yes, I asked about it yesterday, but then I found it in Resources and, seeing the name, I realized that I had it saved on my system all along. And it's strange that I didn't get those error messages when I ran it yesterday -- and the *.err files created overnight were not zero-length.

 

[Z300M]

It's just started the initial parallel seek-stress array read, which is estimated to take almost 30 hours: the parallel read speed is only about one-fourth of the serial speed.

And I think I found the error in the script: a missing space after a '&'