Short of it, it works... the reading part, anyway. I have not tested the writing part yet. CDs and DVDs work, but I have no Blu-Ray data disc, but do have a few Playstation 3 discs. Unsurprisingly, those BDs aren't recognized by the player... a bit of a good sign.
It also tripped my USB 3.0 controller on my laptop, and seems borked since. I would have to reboot it after the data integrity check on the MediaDrive is finished.
WD Drive is fine; 13% hang issue does not show up on the desktop setup for scans. Also clumsy me managed to drop two HDDs during initial second NAS setup.
Also... seems the ASUS P5N-E SLI board's chipset may be dying; while doing a data integrity run on MediaDrive, the onboard NIC cut out and never returned upon reboot. The network power light was on, however, but negotiation lights... nope.
That actually may explain the stability issues beforehand. Simply transferring the entire setup to another board (ironically an older nVidia chipset... but PROFESSIONAL) made the network work again... on the nVidia onboard NIC. The board also has a Broadcom NIC, so I opted to use that instead.
I'm back to doing data integrity checks on the MediaDrive again.
It hanged around 15% of the zero-fill for ~3 minutes, and also there's some slow-down in a few areas. Yeah, I can see why Sis was having very obvious performance issues, even in Windows 7 in its later stages.
Okay, this is postponed. Still prepping for the home web server upgrade, however, since a recent file event has happened, there will be a sweep of the entire old set of data on all three 2TB disks first, then the data on some old storage disks later.
I also remembered: I also changed the SATA cables as well, though that was before the RAM upgrade, and there were still file corruption issues (though lessened) after the SATA cable replacements.
Probably a coincidence re: the cables. However, no more noticeable issues after the RAM upgrade. Seems the board has some odd memory quirks...
Retrieved the data from the laptop drive and am now copying that data to the server as Unsorted.
Will leave a note at that directory regarding the new directory and the existing three: that some of the files have different checksums during transfer in 2021 (what we know so far, anyway).
I now suspect it was possibly RAM related somehow, as there were no known issues with these disks at that time.
Seems some of Sis's video collection have different file hashes between her old laptop and the file server.
This happened before the NAS upgrade in September 2022, so I can rule out my RAID5 setup there. The original copies are still on the old laptop, so I am retrieving those now. But, something's up with the drive installed in the laptop.
I have since changed the RAM somewhere around April 2023. I have also found out that I can use unbuffered ECC RAM on the ASUS P5N-E SLI board; however, it may not actually use ECC on the system.
Finally changing some main paths. Historically, USB drives had a /media directory on Ubuntu; for some reason, hard disks would use this as well. These are finally phased out on this server and will use /mnt as usual.
Seen this behavior on a suspect hard drive with pending bad sectors in August 2021: on a test Windows XP install using a suspect Seagate 320GB HDD, I copied a large archive to the NAS, then I copied that file to the test system. On the test system, the file was corrupt, even after a few retried copy attempts from the NAS. Of course, on the NAS, it was perfectly fine; hashes matched the one on the laptop but not on the test system. Final attempt was to copy that file to the test system using a USB stick, and that eventually worked.
Of course, without file system integrity checks, this is the result. I'm just usually very good at catching these so far.
The site data is on a single 2TB drive, while the database is on a mirrored 80GB setup, though the 80GB one will have to be done as software RAID and not nvRAID this time.
I also suspect nvRAID may have a terabyte bug on this old motherboard, so it's better to use software RAID in the long run anyway.
Seems the file corruption issue no longer occurs after these reallocation events as well. I'll keep watch; will have to get a replacement HDD if it gets nearly bad enough.
On another note, my main webserver OS drive (where this very microblogging instance is hosted) actually has 14 reallocated sectors from the original 0 over the years... and the original issue was a stuck UNC that a zero-write cleared (and the bad sector count remained at 0). That was back in October 2011, when the server was migrated to Linux.
* PCB routing mistakes regarding nSRST - fixed
* Potential safety issue between the JTAG header and DC barrel jack - fixed
* via sizes - changed
* identification text labeling - now present