Oh no, what have I done...

[Chris Ross]

  So, I had a zpool with a single raidz1 in it.  That was fine.  I wanted to make that pool bigger, and learned by researching how to do that that I _can’t_ add a device to the raidz1, as I’d presumed I would do, to just make it larger.  While researching other options, I added a lone device to the pool, somewhat by accident, but then realized “oh wait, that won’t give me redundancy or safety, not what I want…” so tried to take it back out before data got written to it.  However, that appears to not be an option.  After finding that “remove” and “offline” don’t work for that disk vdev, I just pulled the disk.  All the while assuming that since the raidz1 was still kosher, I would find a way to get it running as long as noone wrote a bunch of data to the erroneously attached disk.

  But, I fear I may’ve shot myself.  Is there any way to recover my raid1z vdev from this situation, and get a working zfs pool back?

  Before a reboot, which seems to have made things worse, the pool in question looked:

cross at hyrule[~](576): sudo zpool status tank
  pool: tank
 state: UNAVAIL
status: One or more devices are faulted in response to IO failures.
action: Make sure the affected devices are connected, then run 'zpool clear'.
   see: http://illumos.org/msg/ZFS-8000-HC
  scan: scrub repaired 0 in 10h39m with 0 errors on Thu May 12 09:55:26 2016
config:

	NAME                    STATE     READ WRITE CKSUM
	tank                    UNAVAIL      0     0     0
	  raidz1-0              ONLINE       0     0     0
	    ada1p4              ONLINE       0     0     0
	    gpt/3g01            ONLINE       0     0     0
	    gpt/3g02            ONLINE       0     0     0
	  10950428150510887813  REMOVED      0     0     0  was /dev/da2p1

errors: No known data errors


  Is there anything that can be done here?  A “zfs import” from single user doesn’t seem at all willing to consider it, just fails immediately with I/O error.

  Help?  (And no, of course I don’t have backups!  Technically, it was all data that wasn’t critical and/or could be recovered, but it will take days to reconfigure things, and data will be lost.)

       - Chris


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20170812/87da9d6b/attachment.sig>