Forgot about the hardware requirement, sorry.
SuperMicro X9SCL-F-O mobo, Xeon 1220-V2 CPU, 16 GB Kingston KVR16E11 memory, 3 x Hitachi HDS721010CLA330 1TB hard disks and 3 x HITACHI HUA723020ALA640 2 TB hard disks, Patriot Memory 14 GB USB 3 stick for O/S.
With all the messing around with the hardware, one memory stick went bad; Kinston has agreed to replace it, but I plan to install FreeNAS 11.1 with only 8 GB. As far as I can tell FreeNAS has never used any core memory; that reporting page always says 15.xx Gb is available, so I don't see what difference 8 GB will make -- at least temporarily.
The proximate cause of the FreeNAS crash is easy to relate; it is the long term cause that is somewhat of a mystery. Let me explain.
The FreeNAS directory tree looked like this:
John ZVOL // 3 x 2 TB disks
Mapped to A:\ // Not relevant and not listed.
NAS ZVOL // 3 x 1 TB disks
// Mapped to B:
.recycle // 54 GB of contents; never emptied. One element was a directory named "
Disaster Recovery Planning" (book name)
//
Disaster Recovery Planning would not delete; it caused an I/O error and a reboot every time I tried, whether from the Windows mapping or from the FreeNAS (or Putty) console
D\Docs\Documents // Everything in the Windows Documents folder and sub-folders from the beginning of time
\OldDocs // Documents from a previous Windows system in toto
I // All downloads from beginning of time
J // All Java materials --- SDKs, JREs, demos, code snippets, tutorials, etc
L // Library -- Numerical recipes, boost, etc
N // Misc
V
W
B: was mapped to \\NAS, or rather \\192.168.1.1
so, B:\D\Docs\Documents -> Documents
B:\I -> Downloads, etc.
This mapping made backups incredibly easy, since all I had to do was back up B:, although it was huge, about 90 Blu-ray disks with all files zipped.
Any DIR, XCOPY, or similar Windows commands starting with B:\ failed; it caused the FreeNAS to reboot. I believe this happened because the command encountered the Disaster Recovery Planning directory, was unable to read it, and caused the crash.
If another drive letter was mapped, say, D: =\\192.168.1.1\I, I, J, L, etc. were readable, which is how I backed up most of the FreeNAS contents. D: = \\192.168.1.1\D\Docs\Documents would not read like this, but some sub-directories of it would.
The long term cause of the crash is more mysterious. There is no doubt that the FreeNAS system started continually (i.e., every few minutes) rebooting. There are at least three possible reasons for the rebooting:
1. There are a lot of bugs (small animals) where I keep the computers. Bugs will eat/destroy electronics. The bugs ate enough of the motherboard to stop it from working. The motherboard would not work when I finally shut down the system, although the CPU is OK.
2. I pulled the Ethernet cable out of its socket on the Internet-facing (192.168.0.1) FreeNAS interface. I don't need that except for updates because NTP gets its information from a local computer over 192.168.1.1. So why take the risk? It is a fact that I noticed the rebooting after I unplugged the Ethernet cable, but that could be coincidence.
3. If there are more than a few Windows File Explorer windows open on my main computer, Windows constantly tries to enumerate the B:\directory, from top to bottom. It is possible that there were too many Windows File Explorer windows open, the enumeration was hitting the broken directory in .recycle and forcing the system to crash. This is a long shot, but it could happen.
To reconstitute the FreeNAS system, I plan to install FreeNAS on the computer with a new 32 GB USB stick for the O/S and just the 3 x 2 TB hard disks connected. This should recreate the one working ZVOL. The I would reconnect the 3 blank TB hard disks to the FreeNAS and persuade FreeNAS to create a ZVOL. Then I would copy and verify my backup. Please let me know if you approve or have better idea(s).
Thanks in advance for any help you may care to provide.
Charles Elliott
