Disk added as 'stripe' instead of replacing

[ulchm]

Hey guys,

I messed up when replacing one of my disks that died on my raidz2 array. The single disk now shows up as a stripe instead of replacing the dead drive in my array .

I can't seem to find any way to remove this disk as a 'stripe' so that I can assign it properly. Any help here? I've attached my volume status currently which shows t he degraded array / downed disk and ada3p2 is in it's own group.

 

[joeschmuck]

Backup your important data and recreate your pool. I don't believe you can remove the strip any other way.

 

[Ericloewe]

What joeschmuck said. Back it up, destroy and recreate.

Good thing you realized the mistake now, this could've been dangerous later (still is, but less so).

 

[joeschmuck]

Good thing you realized the mistake now, this could've been dangerous later (still is, but less so).

Oh yes, very lucky indeed, even if it's a pain in the rear to do, it's better than loosing all your data.

So while I'm responding here, thought I'd ask why you have a Log (cache) drive for this system. Do you feel you are getting any benefit from it? This is one of those things you can remove if your pool is at the right location. Also, since you will have to recreate your pool to fix the mistake, it's a great opportunity to easily remove the cache.

 

[DrKK]

Having hung out in #ZFS, and paid attention on FreeNAS now for a year, I can tell you, less than 1 person in 20 using an L2ARC is experiencing any benefit whatsoever from it, and most of them are harming performance. It's one of these things that no matter what anyone says, they just don't think you know what you're talking about when you tell them it's not useful in their usecase to use an L2ARC.

 

[DrKK]

And yes, OP, once you stripe in a vdev, it's game over. The pool cannot unstripe any vdev. You have no options other than recreating the pool from scratch.

ZFS is very unforgiving for mistakes. Remove the cache, like joe says, while you're at it.

 

[ulchm]

thanks for the replies. There's no way I can back up my data unfortunately since I don't have enough storage for it. This sort of thing is kind of a major deal and should be very clearly marked with warnings in freenas to prevent it imo. I understand it's user error, but it's not like anything I clicked / read seemed at all obvious that I wasn't replacing a drive and instead creating a 'stripe'. I don't even remember seeing the world stripe used anywhere.

So I guess I'm screwed and going to be forced to return this drive, get a new one and run my array in a permanent degraded state with a drive disconnected.

The cache drive is there only because I had an SSD I wasn't using and wanted to see if it made any difference (it didn't).

Thinking this is going to be the end of my freenas experiment, back to lvm / mdadm!

 

[DrKK]

A couple of things.

Do *NOT* run this pool, at all, much less than in a degraded state. You now have an Achilles' Heel---if your striped in drive fails, THE WHOLE POOL GOES DOWN. Plus you're at risk due to the degraded initial vdev as it is. Again, in a zpool, if you lose ANY vdev, you LOSE THE POOL. You have a vdev consisting of ONE DRIVE. If that one drive goes down, you lose the whole pool. Your other vdev is degraded---if that goes down, you lose the pool. Your NAS is now a timebomb that puts your data at more risk than any other solution---for example, the situation is now worse than just an external USB drive plugged in with no redundancy.

Second of all, our "replacing a drive" documentation is click-by-click, and well outlined in the documentation. We are very clear that ZFS/FreeNAS is very unforgiving of mistakes, and no one should click anything until they know exactly what they are doing. I, myself, am scared to do anything until I am absolutely positive I know exactly what's going on. FreeNAS/ZFS is a nightmare for the "tinkerer" "player-around-er". We can't put disclaimers on everything. I'm sorry you had a nightmare scenario unfold, to be sure, but really, none of that blame can be placed on us. How the hell is FreeNAS supposed to know that the drive you're putting in is a replacement drive unless you TELL it?

FreeNAS is not for everyone. It is *MOST ESPECIALLY* not for Linux tinkerer/hacker types who are accustomed to just trying things and learning on the job. The flexibility of the product, and the subtlety of the product, means that you have more than enough rope to hang yourself with FreeNAS. I read about FreeBSD and the entire FreeNAS manual for about 6 weeks before I put a single byte of data on hardware.

 

[ulchm]

this pool is running and will continue to until a drive dies and I have to replace the pool, there's nothing else I can do at this point. thanks anyway

 

[DrKK]

Well, the good news is, it won't be long.

Suggest you back up as much data as you can.

 

[gpsguy]

You could add another drive to mirror the single drive. You'd have to do that through the command line - look on the forum for instructions.

If that single drive fails, you'll loose everything.

... there's nothing else I can do at this point

 

[danb35]

it's not like anything I clicked / read seemed at all obvious that I wasn't replacing a drive and instead creating a 'stripe'.

Nothing you clicked or read said you weren't launching nuclear missiles, either. What's much more important was that nothing you clicked or read said that you were replacing a drive, nor was anything you clicked anywhere close to how TFM tells you to replace a disk.

FreeNAS is powerful and flexible, and with that power and flexibility comes the ability to do some really dangerous things. If you just jump in without reading the available documentation, your chances of doing one of those really dangerous things increases exponentially. You appear to have done the former, and have certainly done the latter.

 

[DrKK]

You know, @danb35, he was already lightly chastised. He doesn't need a second, less diplomatic dose.

Also, gpsguy's idea is a good one, OP. If you put a mirror on top of the single drive (one of the rare times you're allowed to change an already-deployed vdev), you will improve your situation. I would describe the result as "code yellowish-red" rather than "code uber saturated pigeon's blood red", in terms of danger.

 

[danb35]

Fair enough. The "nothing told me I wasn't replacing the disk" clearly rubbed me the wrong way, but that doesn't make my response any more productive.

 

[ulchm]

I'm currently backing up everything I can and will redo the array momentarily.
Thanks for all of the advice guys, it's certainly a lesson learned the hard way.

One more question for anyone still following, since I will be removing the cache drive should I be using that SSD to boot from instead of usb thumbdrive?

 

[danb35]

There's really no benefit to booting from an SSD rather than using a USB stick. The initial boot will be a little faster, but after that, everything is loaded into a RAMdisk anyway. It won't hurt to use the SSD as a boot device, but it really won't do anything for you either. I'd vote to save it for something more useful.

 

[ulchm]

will do that thanks.

 

[joeschmuck]

Good luck in backing up your data, I'm sure you will get it all before a failure occurs (fingers crossed).

But I agree that it would be nice if the FreeNAS application were smart enough to warn you against a serious mistake, but it doesn't right now. Maybe in the future.

 

[DrKK]

@joeschmuck

You might have a point in this case. It's almost never correct to have a 1-device vdev striped into a pool. It might be simple enough to give a "ARE YOU SURE" dialog. You want to propose it in the bug tracker?

 

[Ericloewe]

Maybe if said warning was only shown when striping individual drives with RAIDZ vdevs? Adds some complexity, but removes the "someone might want to do it" argument.