The hexdumps from sdj and sdk seem to be entirely missing their labels from the expected offset of 0000c000 onwards - they’re not just “corrupt”, they’re zeroed all the way to 00019000 - normally, I’d think this is a case of the wrong partition offset, and the labels would just be elsewhere.
What does the last 32MB of your partition show?
Your partition layout seems to be identical to sdc and sdd which say they’re members of zpool - but you said you expect your pool name to be zpool4t (for the 4T size of the member disks I assume) which isn’t showing anywhere in the label either.
Was this pool made initially from these five disks, or was there a replacement/swap for either expansion (replacing smaller with larger) or failure reasons?
I uploaded it on https://drive.google.com/drive/folders/1Yrd2e2dEOhB78c0 cGHkUot2ch82SFamx?usp=sharing
I added emojis to prevent search engines from crawling.
I forgot how I formatted the drives at that time. Did I use some feature of the web UI? Back then, I formatted the hard drive because there was an issue with support for CJK filenames. After formatting, I used the following command to move the files back into the pool.
This is what I found from history which created my pool.
I seriously suspect I was being stupid at the time. I unassigned the ZFS pool from the web UI, but doing so didn’t actually destroy the pool. Then I directly created a new pool on top of the old pool. To be honest, I can’t remember what I did at the time.
I haven’t ever messed with the ZFS support in UnRAID, so I don’t know what the expected method of creation through the webUI or CLI is - but from your zpool create command:
You appear to have passed full disks as opposed to partitions, and picking apart the dump of the tail end of the disks there, I’m guessing that stomped all over whatever automatic partitioning scheme was used by UnRAID in the GUI. Using the -f flag cemented it into existence as well rather than giving ZFS a chance to throw up an error along the lines of “I see existing labels, are you sure you want to do this?” so that is likely further contributing to the issues here.
You definitely created a pool on top of a pool. I can see overlapping labels with different GUIDs on sdc, see the two segments below and the different hex after the pool_guid line:
On sdd I see the remnants of a Windows EFI boot manager as well at the tail so this disk didn’t get cleared properly by whatever added it to a pool in the first place.
The command that followed this line was the zpool create - just so we’re clear, did you move the files off the pool first, or did you just try to create a new pool on top of the old one? Because if the aim was just to rename the pool, that doesn’t involve create - you can just import with oldname newname and change it that way.
I wanted to recreate the pool because I wanted to add the two parameters: “-O normalization=formC -O utf8only=on”. As far as I remember, I cut all the files to another location before performing the operation I mentioned earlier. I really regret doing this through the web UI. But what’s strange is that I had restarted several times before, and there were no errors.
I don’t know why there exists a Windows EFI boot manager. I haven’t installed an operating system on it; maybe it’s the installation image of the operating system?
With the inconsistent/ambiguous labels you have, it’s likely that you were basically doing a “coin toss” on each boot, and previously you were “winning” the coin toss.
I’m not sure if there’s a way to explicitly force zpool import to look at a specific label for import - but what happens if you ask zdb -lu /dev/sdc directly, without specifying a partition? Does it show the zpool4t pool correctly there, I wonder?
Since you have full backups of the drives (bit-for-bit copies, I assume?) we might be able to take riskier steps - such as zeroing the zpool related labels on a single disk and seeing if ZFS will grab the zpool4t ones automatically.
You’ll have to quite directly dd if=/dev/zero using the oseek option to skip a certain number of bs-sized blocks on the target.
I’m going to want to test this out myself to see just how it will react to a completely absent label, but you’re basically going to obliterate the ambiguous data and hope that it will pick up the correct one. That’s assuming the remaining label is intact and points to a functional/active pool.
Could you tell me the details? To be honest, I’m not familiar with file system. How can I determine exactly where I should overwrite? Is there any way to figure it out? Thank u really much.
Can you tell me where I can find documentation about the binary-level structure of ZFS? I’ve been searching for a long time but haven’t found anything.