Bit weird that zpool status isn't telling you which disk is faulting…
That could mean the TB cable, power to the thunderbay is not great, or backplane failure might be in the mix (although rare)
I have had an old HP box behave perfectly running FreeNAS, but as soon as there's any disk significant activity to read data off the pool, it would just reboot…
Was caused by faulty power supply…
Suss all your power… don't use power boards… plug directly into the wall!
The TB cable… how long is it? it has to be under 400mm, 12inches if we're talking Thunderbolt 3 connectivity.
Reseat the TB cable… ensure it's connected firmly and ensure the weight of "something" such as the cable itself is not pulling on the port and creating tension in any way…
I really dislike USBc/TB3 physical connections… they feel flimsy at best!! and feel like they can be "flicked" out of the socket with very minimal unintentional effort…
Don't have anything else connected to your Mac other that its power. (just to test)
If all seems in order, let's move onto the disks...
You want to rule out hardware issues before we look at software issues…
So… These drives… are they SMC?
https://www.youtube.com/watch?v=aztTf2gI55kLinus (and Serve The Home) mention they are a "no go" for ZFS.
With that out of the way.
Recreate your pool but zero out all your disks first…
Warning! this is dangerous and so disconnect all other external disks you may have…
To do this, the command is:
- Code: Select all
sudo dd if=/dev/zero of=/dev/diskn bs=1024 count=100
Explanation:
if = input file = zeros to be written to the disk
of = output file = diskn where n will most likely be 1 to 8. You need to check/verify this, so in terminal app type:
- Code: Select all
diskutil list physical
to see your real/physical disks to be sure.
bs = block size
count = how many blocks to write zeros from the start of the disk.
We only want to wipe out the start of the disk where the partition map exists.
Now recreate your pool… zpool create thunderbay8 raidz2 disk1 disk2 disk3 disk4 disk5 disk6 disk7 disk8
(you can add all the yummies such as atime, compression, checksum etc later… right now, we just want to test the hardware…
as for casesensitivity=insensitive and normalization=formD, I'm not even sure what we should be opting for now when it comes to normalisation… FormD was for HFS and so not sure what to choose to mimic APFS atm… Mr Lundy?
Open a terminal windows and type zpool iostat -v thunderbay8 1 100000
This will show you exactly how much Input/Output (I/O) count and also megabyte read/write each disk and the single vdev and thus pool is achieving… (handy to know at any time!)
Now in another/new Terminal window:
install brew…
https://brew.sh shows you how in the terminal which is a just a "one liner" command to install. (brew will become your friend!)
so that you can install iozone. (brew install iozone)
then… in the same/2nd Terminal window, change directory to your pool… (cd /Volumes/thunderbay8) and run time iozone -a, as per the wiki here…
https://openzfsonosx.org/wiki/PerformanceThis will give your newly pool a good workout for a good couple minutes…
In a third Terminal window, periodically run zpool status to see the health of your thunderbay8 pool… zpool iostat in the first Terminal windows will also show you if you have issue if all the values drop to zero… (not nice to see)
If you get a repeat of the errors you saw initially… it's time to observe in the Terminal window that you're running zpool status to see if any disk has become "cactus"… if so… shut down open up the thunderbay and reseat your SATA connections…
Check power connections also and it wouldn't hurt to reseat them as well.
I always write (via sticker or grey lead) the Serial number on the disks in the array so that I can see them the the pool is up and running… this wa it helps to identify which disk (in future) is causing you grief.
this might work for you given your external disk are connected via SATA
- Code: Select all
$ system_profiler SPSerialATADataType -detailLevel medium | grep Serial | sed -e 's/[\<\>\"\ ]//g' | -F':' '{print $2}'
boot up again, use Terminal to check the status of your pool and hopefully all is well…
If the same disk (hopefully only one!) is still missing and not resolving now, then shutdown and swap the disk to another a bay…
Boot up again and see if you can identify if it's the disk still… or whether it's the bay…
If it's the bay, you should have a 2nd disk that's now cactus and so it's time to contact the vends and return it under warranty…
If it' just the same disk that's cactus then it's also vendor time and test the disk in the array all by itself using ZFS and see if you get continual errors…
I have performed the above to identify a disk that is not healthy and did a RMA with Seagate… they replaced the disk for me no probs, but it took a couple weeks before I got a replacement (Australia) so it doesn't hurt to go buy another one anyway and keep as a cold spare… or use it as a single disk in other areas if you're keen…
See how you go and report back.
(fingers crossed for you)