Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

So my the USB drive attached to my FreeNas 7 system, went bad so I used the situation as an opportunity to upgrade to FreeNas 8. The problem is now I'm having trouble getting my ZFS to spin up:

[root@media] ~# zpool import
  pool: filetank
    id: 17702465758427828599
 state: FAULTED
status: The pool was last accessed by another system.
action: The pool cannot be imported due to damaged devices or data.
    The pool may be active on another system, but can be imported using
    the '-f' flag.
   see: http://www.sun.com/msg/ZFS-8000-EY
config:

    filetank    FAULTED  corrupted data
      raidz1    FAULTED  corrupted data
        ada3    ONLINE
        ada1    ONLINE
        ada4    ONLINE
        ada2    ONLINE
[root@media] ~# zpool import -f filetank
cannot import 'filetank': one or more devices is currently unavailable

What's weird is that just the raidz says its corrupted and I'm not sure what to do about it. Most stuff I can find involves replacing an individual device, but it doesn't look like any particular device has failed? I went back to FreeNas 7 and got the same error, which is basically what I expected.

share|improve this question
    
The pool was not exported before you moved it, so the disks are still "in use" by the previous OS. ZFS is not just a file system, it's disk management too, be sure to understand the ramifications of that. –  Chris S Jan 21 '12 at 22:36

2 Answers 2

up vote 3 down vote accepted

Try zpool import -f -F -n filetank.

That will not actually import the pool, but will tell you if it's recoverable.

If it gives you the green light, then proceed:

zpool import -f -F filetank

Details on these options, from the man page:

     -f

         Forces import, even if the pool appears to be poten-
         tially active.

     -F

         Recovery mode for a non-importable pool. Attempt  to
         return the pool to an importable state by discarding
         the last few transactions. Not all damaged pools can
         be  recovered  by  using this option. If successful,
         the data from the discarded  transactions  is  irre-
         trievably  lost.  This option is ignored if the pool
         is importable or already imported.

     ...

     -n

         Used with the -F recovery option. Determines whether
         a  non-importable pool can be made importable again,
         but does not actually perform the pool recovery. For
         more  details  about  pool recovery mode, see the -F
         option, above.
share|improve this answer
    
So: A. The version of zpool I have apparently doesn't have the -F -n flag (invalid option 'n') B. Doing just -F gives me "cannot open 'filetank': no such pool" Any other ideas? :-/ –  ultramiraculous Jan 24 '12 at 12:40
    
"no such pool" seems like a strange error to get - is it still finding the pool when you just try to do the import normally? –  Shane Madden Jan 24 '12 at 15:51
    
Yeah, it only gives that error with the -F, which is really weird to me. These are the messages I get with the different flags: zpool import filetank -> cannot import 'filetank': pool may be in use from other system, it was last accessed by ..., then zpool import -f filetank -> cannot import 'filetank': one or more devices is currently unavailable, and zpool import -f -F filetank -> cannot open 'filetank': no such pool –  ultramiraculous Jan 25 '12 at 0:05
    
Booted up from an OpenIndiana image instead. -F -n, then -F worked like a charm. Lost a second of transactions from a few months ago (huge loss). Thanks! –  ultramiraculous Jan 26 '12 at 7:09
    
@ultramiraculous Nice! Glad to help. –  Shane Madden Jan 26 '12 at 7:17

Try importing it using its numeric identifier (the id). This often does magic.

zpool import -f 17702465758427828599

You may be running into an old ZFS import bug here that causes forced imports to only be possible when doing it by id. See an explanation in the comments to this post.

If this resolves the problem I'm glad.

If it does not you should check your logs for zfs complaining about checksum mismatches. If this is the case you'll probably want to see what zdb -l /dev/dsk/ad* tells you about your disks as it would mean corrupted metadata.

share|improve this answer
    
The identifier has nothing to do with that command. You've got -f in there, which forces ZFS against any common sense warnings. –  Chris S Jan 26 '12 at 1:32
    
I know, but there has been a bug in ZFS, where it wouldn't force import filesystems by name claiming it didn't know the name. May still be in there unless you checked and are positive it is not. In that case importing by id still works. –  juwi Jan 26 '12 at 1:34
    
That bug was resolved in ZFS about a year ago. It also manifested itself as cannot open 'poolname': no such pool, not the error reported here. –  Chris S Jan 26 '12 at 1:42
    
Please read the posters comment on the post above, where you will see, that this is exactly the error he reports when using -f -F. Also while FreeNAS 8 is about a year old now, it inherits the Kernel and ZFS Version of FreeBSD 8.2 which had its Code Freeze in November of 2010. The last import of ZFS Code has been prior to that. So if the bug was resolved about a year ago, chances are it got fixed afterwards and has not made it into a patch to FreeNAS. –  juwi Jan 26 '12 at 2:24
    
Hrm, good points. This may be a problem he's encountering, but isn't the root problem. I'll rescind my downvote if you edit your Answer (the vote is locked in until your Answer changes). –  Chris S Jan 26 '12 at 3:28

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.