We have 3 JBOD drives set-up... one as a shared network drive (12TB), and two 8TB units one of which is the primary drive, and the other a backup to that drive and which also holds the individual system backups for all the networked computers. The reason for this is that this configuration is to deal with and encode RAW video, HD and otherwise, and we need ALL the files to be instantly accessible and searchable (with basic metadata), and spotlight is such a POS, that it has been unusable since it's inception. I don't need lectures on spotlight or the use/build of JBODs/RAIDs, so if, like on many of the searches I made here, that is your goal... please don't.
At issue, is that for the first time in 3 years, we are now experiencing problems with the primary JBOD drive. Unfortunately, there is no software that comes with OSX, or in about 15 different backup and recoveries softwares that allows any form of information retrieval or maintenance on such drives... no SMART info is available from any of the 12 individual SATA drives involved, no software we have sees the drives individually, and most don't even recognize the drives as a single JBOD. Most softwares only see a drive if it is mounted on the desktop, and they only see it as it is presented via the OSX system (so CCC and Disk Warrior see them sufficiently for their job, but iPartition fails miserably in any form, and it and TechTool are horrifyingly dangerous to operate with a JBOD mounted).
This means we have no way of determining which of the 4 drives in the primary set is failing, only that as it is doing so, it is leaving bad sectors which are being ignored by both the system and any hardware on the actual drive... our only notification that this was happening was that when the file was accessed (the actual contents read, not just the headers and TOCs), the resulting I/O error force unmounted the drive from the system, claiming we had disconnected it. This occurred during two backup attempts, which led us to the diagnosis... as soon as we removed the files from the backup process, the I/O error and forced dismount stopped. This was then confirmed by just attempting to read the file without any actual loading... quickly confirming it when the drive dismounted halfway through the read (but as the indicator lights on three of th drives were blinking, there was no way to figure which one).
We then attempted to use three different programs to locate the affected sectors (using a sector scan, which is supposed to locate AND mark the sectors). But, as scanning 8TB would take a day via eSATA (god forbid firewire or USB), when we got back each time, after leaving the various softwares running overnight (or over the weekend), we discovered none of them survived when they finally came across the sector(s) affected. When the drive got dismounted, every one of the softwares crashed out (IIRC one caused OSX or the GUI to hang, and a cold reboot was required). Thank the Lord for log files, even though they aren't very detailed.
Also note that the main system is a G5 quad running OSX 10.4.11, under hardware and software necessity, and that, even though we have 10.5, it is only used during times when other work is not on-going (typically during only about 16 hours on Sundays). So software CANNOT be MacIntel, or require OSX over 10.5.
So, with this knowledge, the questions are:
1. Is there a software package that can recognize and locate bad sectors, without crashing/unceremoniously dismounting the drive?
2. Is there a software package that can locate the exact position of the data of a file (without actually reading the data itself), across a JBOD or other RAID configuration (drive, tracks, sectors)? Is this available via a terminal/unix command?
3. Is there recovery software that can access the files on the good drives in the set? (don't need this now, but might need it in the future)
4. Is there a general drive software that is actually aware of Apple's software RAID set-ups, and is configured to deal with them?
5. Is there any way to retrieve SMART data from drives across eSATA or a chipset that doesn't normally do so in a drive enclosure(s)?