Does this mean I need to reconfigure my zpool?

[KempelofDoom]

Does the below mean I have a RAIDZ1 with 3 RAIDZ2 arrays?

Code:

[chris@freenas] ~% zpool status
  pool: pool
state: ONLINE
  scan: scrub in progress since Wed Oct 15 04:25:04 2014
        2.14T scanned out of 31.6T at 1.94G/s, 4h19m to go
        0 repaired, 6.78% done
config:

        NAME                                            STATE     READ WRITE CKSUM
        pool                                            ONLINE       0     0     0
          raidz2-0                                      ONLINE       0     0     0
            gptid/e5010213-5196-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
            gptid/e5b7459d-5196-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
            gptid/e672959a-5196-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
            gptid/e72f833c-5196-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
            gptid/e7ea107d-5196-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
            gptid/e8a02420-5196-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
          raidz2-1                                      ONLINE       0     0     0
            gptid/e94afdfd-5196-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
            gptid/e9ec4ac2-5196-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
            gptid/eaa90d6d-5196-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
            gptid/ec538402-5196-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
            gptid/edd3db9f-5196-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
            gptid/ee989f92-5196-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
          raidz2-2                                      ONLINE       0     0     0
            gptid/ef529d7a-5196-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
            gptid/efff7851-5196-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
            gptid/f0ab8677-5196-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
            gptid/f15b8b20-5196-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
            gptid/f20a75ac-5196-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
            gptid/f2b96afe-5196-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
          raidz1-3                                      ONLINE       0     0     0
            gptid/125f976d-5197-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
            gptid/140d2812-5197-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
            gptid/16005f52-5197-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
            gptid/16e08ff7-5197-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
            gptid/178df4e3-5197-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0
            gptid/18c24756-5197-11e4-9e38-0cc47a0411b8  ONLINE       0     0     0

errors: No known data errors

 

[Ericloewe]

Proper terminology is very important, otherwise nobody will understand what you're saying. If you want to read up on that, read Cyberjock's presentation.

Now, first of all, it's a bad idea to name your pool "pool". That kind of thing will quickly escalate into commands that misbehave. Same goes for a few other words I don't remember at the moment.

As for the pool, it's made up of three RAIDZ2 vdevs and one RAIDZ1 vdev. The RAIDZ1 vdev might bring you pain in the future.
To properly set this up again (with four RAIDZ2 vdevs), you'd need to destroy the pool and rebuild it from scratch, then copy the data back into it from backups.

 

[KempelofDoom]

Proper terminology is very important, otherwise nobody will understand what you're saying. If you want to read up on that, read Cyberjock's presentation.

Now, first of all, it's a bad idea to name your pool "pool". That kind of thing will quickly escalate into commands that misbehave. Same goes for a few other words I don't remember at the moment.

As for the pool, it's made up of three RAIDZ2 vdevs and one RAIDZ1 vdev. The RAIDZ1 vdev might bring you pain in the future.
To properly set this up again (with four RAIDZ2 vdevs), you'd need to destroy the pool and rebuild it from scratch, then copy the data back into it from backups.

DAMN, I was afraid of that. Damn auto vdev config tool wouldn't let me create a vdev using 4 3TB and 2 4TB drives as RAIDZ2. Hello 6 more days of transferring data back and forth.

 

[Ericloewe]

DAMN, I was afraid of that. Damn auto vdev config tool wouldn't let me create a vdev using 4 3TB and 2 4TB drives as RAIDZ2. Hello 6 more days of transferring data back and forth.

You can certainly do that manually, but you'll be limited to using 3TB of the 4TB drives until you replace the 3TB drives with larger drives.

 

[KempelofDoom]

You can certainly do that manually, but you'll be limited to using 3TB of the 4TB drives until you replace the 3TB drives with larger drives.

I did do that manually but I probably forgot to choose RAIDZ2 when I set it up and added it to the other zvol's.

 

[SirMaster]

If you are adding vdevs manually always use the -n flag for dry run which will show you what the pool will look like after you actually run the command without -n so you can make sure it's what you want.

 

[KempelofDoom]

If you are adding vdevs manually always use the -n flag for dry run which will show you what the pool will look like after you actually run the command without -n so you can make sure it's what you want.

I used the web interface to create the first 3 vdev's but it wouldn't let me create the 4th because of the 6 disks left, 4 were 3TB and 2 were 4TB. So I did that one manually via the web interface and had it added to the pool that the other 3 were a part of. I just missed selecting RAIDZ2 when doing so and go myself into this mess.

 

[SweetAndLow]

If you are adding vdevs manually always use the -n flag for dry run which will show you what the pool will look like after you actually run the command without -n so you can make sure it's what you want.

Yeah don't listen to this comment. You should never be using the CLI when messing with your pool. You did the right thing by using the manual WebUI method, just make sure to select RaidZ2 this time. :)

 

[Ericloewe]

Doing stuff via the CLI is going to cause a lot of weird issues...

 

[KempelofDoom]

Doing stuff via the CLI is going to cause a lot of weird issues...

Which is why I avoided doing that. After taking things for granted and not RTFM, CyberJock schooled me to reality and I read his guide for noobs which really helped and strictly states to NEVER use CLI unless under the guidance of professionals. ;)

 

[cyberjock]

Good on you for not using the CLI. Here's a cookie!

:D

 

[SirMaster]

Yeah don't listen to this comment. You should never be using the CLI when messing with your pool. You did the right thing by using the manual WebUI method, just make sure to select RaidZ2 this time. :)

I just don't understand this...

If he did the "right" thing then why did he get the incorrect result? Doing the right thing should produce the right result. As a software developer that simply screams "defective product" to me and it should be fixed.

If he instead did what I suggested, what an intelligent and informed user *should* do then he could have seen his mistake before making it and he would not be in this problematic situation at all.

I'll never understand why people are so adamant on hiding behind GUIs. That sort of mentality causes problems. You don't have to take my word for it. This thread already unequivocally proves that statement.

The other regulars here know that this is NOT the first case where a user has made unintended changes to their zpool by using the GUI. This is NOT an isolated event. Clearly there is a problem that they seem to be ignoring... for whatever reason I do not understand. It seems a rather important issue to address to me when the only solution is to destroy and recreate the pool which is quite a drastic solution.


ZFS was never designed to be administered from anything but the CLI. This is also an indisputable fact. Now I know many users on this forum always preach about doing things the "correct" way, and the "intended" way. If they have any integrity whatsoever then there is no say they can say with a straight face that the "correct" and "intended" way to administer their ZFS is with a GUI, and a GUI with clearly missing features at that.

Now you are going to say "users will screw up their pool with the CLI too".

I will not dispute that very likely possibility because I agree with that statement as well. But it's clear that multiple users are screwing up their pool via the GUI already as well. The difference though that I am concerned with is that the GUI does not provide the correct and intended ZFS mechanism to prevent unintended pool modification issues such as these, so how can it truly be the "better" way?

Giving users the CLI actually forces them to take charge of their own fate and take the time to learn about the system they are trying to administer before using it and that makes for a much better system and a much smarter user who will in the long run be better equipped to handle their server.

That's my opinion at least whether you agree with it or not. That's all I wanted to make understood by other users who might read this.

 

[Ericloewe]

I just don't understand this...

If he did the "right" thing then why did he get the incorrect result? Doing the right thing should produce the right result. As a software developer that simply screams "defective product" to me and it should be fixed.

If he instead did what I suggested, what an intelligent and informed user *should* do then he could have seen his mistake before making it and he would not be in this problematic situation at all.

I'll never understand why people are so adamant on hiding behind GUIs. That sort of mentality causes problems. You don't have to take my word for it. This thread already unequivocally proves that statement.

The other regulars here know that this is NOT the first case where a user has made unintended changes to their zpool by using the GUI. This is NOT an isolated event. Clearly there is a problem that they seem to be ignoring... for whatever reason I do not understand. It seems a rather important issue to address to me when the only solution is to destroy and recreate the pool which is quite a drastic solution.


ZFS was never designed to be administered from anything but the CLI. This is also an indisputable fact. Now I know many users on this forum always preach about doing things the "correct" way, and the "intended" way. If they have any integrity whatsoever then there is no say they can say with a straight face that the "correct" and "intended" way to administer their ZFS is with a GUI, and a GUI with clearly missing features at that.

Now you are going to say "users will screw up their pool with the CLI too".

I will not dispute that very likely possibility because I agree with that statement as well. But it's clear that multiple users are screwing up their pool via the GUI already as well. The difference though that I am concerned with is that the GUI does not provide the correct and intended ZFS mechanism to prevent unintended pool modification issues such as these, so how can it truly be the "better" way?

Giving users the CLI actually forces them to take charge of their own fate and take the time to learn about the system they are trying to administer before using it and that makes for a much better system and a much smarter user who will in the long run be better equipped to handle their server.

That's my opinion at least whether you agree with it or not. That's all I wanted to make understood by other users who might read this.

FreeNAS keeps track of stuff when the GUI is used. Using the CLI will not update the database, which will lead to weird behavior due to the inconsistency. There is no choice when using FreeNAS. This isn't some random "You're too stupid for CLI." feeling.

 

[SweetAndLow]

As a software developer you should understand that not all users of a piece of software are going to know how it actually works. They want to just use it as a tool to help then accomplish a goal. FreeNAS has the goal of trying to make a complicated OS/Filesystem usable by everyone. This is why it has a GUI and not to mention all enterprise NAS filesystesm(Isilon, NetApp, VNX) have a gui as well and you are expected to use the gui to administer those filesytesm also, even if it is being administer by someone with 30 years experience. From the CLI you can make this same mistake that this user made as well as even worse mistakes. This is what the GUI removes, the ability to make that big mistake that you can't recover from. Also FreeNAS expects things to be done through the GUI and be configured in a certain way. When you go around the GUI you will most likely miss a step and then your pool can no longer be mounted properly.

When I said he did the right thing I was making a comparison to him using the GUI where as you said to use the CLI. I was making sure to point out to other people reading this later that using the CLI like you said is not the right way to do it no matter how many people say "well it worked for me". When people start using the CLI they just start copy pasting commands from the internet and who knows what they are going to get.

 

[SirMaster]

Can you give examples of some ZFS commands that when run from the CLI normally would get updated in the database when run from the GUI? I would be curious to find out details about them.

Certainly these commands that update the database are not crucial to zpool health and configuration since with FreeNAS it's possible and a standard workflow to be able to import your pool a new new fresh FreeNAS installation with a fresh new database. Certainly this fresh new database has none of these GUI operations tracked anymore since it's a fresh new database.

And I would bet "zpool add" is not one that's tracked in the database for any crucial operational reason.

 

[SirMaster]

This is what the GUI removes, the ability to make that big mistake that you can't recover from.

I understand that you can't expect users to know "how it all works." But that's equally true of both GUI and CLI systems, it doesn't really favor one or the other.

But do you not see the problem here from what you said?

My point is the GUI did NOT do what you said it's main purpose is.

The user used the GUI and the user "made that big mistake that he can't recover from" (short of complete pool destruction). And again, that's my main concern here since this is not the first or even second case of this issue I have seen users report here.

I believe in specific that a "zpool add -n" CLI command is the better way to handle what the user did until such a time that the GUI provides a comparable mechanism to prevent unintentional pool modifications.

I know I would always be somewhat leery of GUIs touching my zpool because I don't really know what they are doing and they might do something I didn't really want because they forgot to tell me about it.

Hiding information is a dangerous thing in my experience.

 

[Ericloewe]

Can you give examples of some ZFS commands that when run from the CLI normally would get updated in the database when run from the GUI? I would be curious to find out details about them.

Certainly these commands that update the database are not crucial to zpool health and configuration since with FreeNAS it's possible and a standard workflow to be able to import your pool a new new fresh FreeNAS installation with a fresh new database. Certainly this fresh new database has none of these GUI operations tracked anymore since it's a fresh new database.

And I would bet "zpool add" is not one that's tracked in the database for any crucial operational reason.

Your best bet is to ask on IRC and see if you catch a dev.

 

[SweetAndLow]

Off the top of my head just by doing a zpool add you will mess things up. Because you also have to partition the disk properly and setup the gptid's

 

[SirMaster]

Off the top of my head just by doing a zpool add you will mess things up. Because you also have to partition the disk properly and setup the gptid's

Correct, but I never said anything along the sorts of adding raw block devices. And with the -n option you would again clearly see that the vdev about to be added was displaying block device names rather than gptid's/partitions like your existing vdev(s) so you would see that something is wrong and something is not like the other.

Anyway IMO I think users should be encouraged to learn about how their system works, including the CLI in order to better administer their system rather than always be encouraged to forever hide behind the GUI and just "nevermind how it works".

There is nothing inherently wrong with users who want to stick with 100% GUI assuming it all works correctly. But I don't think everyone should be completely discouraged here from learning beyond the GUI.

I can't help but feel like that mentality is a little 1984ish :p

Otherwise I can certainly understand, appreciate, and cater to both camps of users.

 

[cyberjock]

Can you give examples of some ZFS commands that when run from the CLI normally would get updated in the database when run from the GUI? I would be curious to find out details about them.

Certainly these commands that update the database are not crucial to zpool health and configuration since with FreeNAS it's possible and a standard workflow to be able to import your pool a new new fresh FreeNAS installation with a fresh new database. Certainly this fresh new database has none of these GUI operations tracked anymore since it's a fresh new database.

And I would bet "zpool add" is not one that's tracked in the database for any crucial operational reason.

imports, exports pool creation.. want me to go on?

Bottom line, you are NOT someone that has the necessary experience to even argue this. It is what it is. If you don't like it go find a new product. But don't sabotage forum users that don't know better and think you are giving them sound advice. You aren't.

As for the argument that the WebGUI is broken because it was improperly used, when someone can provide a repeatable case where it is broken, we will have a bug and fix it. We've had none of those that I am aware of and screwed up pool creation has always been the result if user error. Well, guess what.. you could user error the CLI, and that's much easier to do than the WebGUI which provides visual indication of what's going on.

Sorry, but your argument is invalid.

I'm locking this thread too. Don't need a flamewar started on this thread. The OP asked a question and he got the answer. It wasn't what he wanted, but he admitted he might have screwed it up. In any case, if there's a bug and we can repeat it, then put in a ticket at bugs.freenas.org. If you can't repeat it, then it was likely user error. If you still aren't satisfied, grab the FreeNAS code from github and fix it yourself. Pull requests to the FreeNAS master branch are always appreciated.

Thanks to everyone that participated.