SOLVED This look normal to you...? (.system "Error getting available space")

[SilverJS]

As per title. Trying to do a lot of clean-up of my pool. Got rid of annoying messages created by a bug in jail creation in 9.2, so that's good (search engine victory! =)). Now, there's this :

http://imgur.com/1YqJATO

EDIT : System part collapsed, for perspective :

http://imgur.com/LvVYcLx

I did search, but didn't come up with anything. Running 9.2.0, 8 GB ECC RAM, Asus Mobo with Athlon X2 255 (X10 with G3220 inbound - just want to clean things up before upgrading to 9.3 on the new hardware.)

 

[SweetAndLow]

output of zpool status? I have a feeling your pool is having major issues.

 

[SilverJS]

All's tickety-boo, as far as I can see...

[Scrub was cancelled as I was in the midst of the first Replication to my back-up server, about 4TB of data. And I know about the block size thing, my ashift is 9...not sure yet if I'll live with it or just totally rebuild pool from the backup.)

zpool status Raidz2
pool: Raidz2
state: ONLINE
status: One or more devices are configured to use a non-native block size.
Expect reduced performance.
action: Replace affected devices with devices that support the
configured block size, or migrate data to a properly configured
pool.
scan: scrub canceled on Sun Mar 22 00:21:49 2015
config:

NAME STATE READ WRITE CKSUM
Raidz2 ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
gptid/2667ab53-cabf-11e0-90d6-f46d04ee3b78 ONLINE 0 0 0 block size: 512B configured, 4096B native
gptid/278855cd-cabf-11e0-90d6-f46d04ee3b78 ONLINE 0 0 0 block size: 512B configured, 4096B native
gptid/28ba1288-cabf-11e0-90d6-f46d04ee3b78 ONLINE 0 0 0 block size: 512B configured, 4096B native
gptid/29dd22a5-cabf-11e0-90d6-f46d04ee3b78 ONLINE 0 0 0 block size: 512B configured, 4096B native
gptid/fd2ee8c9-e38c-11e2-bc79-f46d04ee3b78 ONLINE 0 0 0 block size: 512B configured, 4096B native
gptid/2f756925-9267-11e2-aed5-f46d04ee3b78 ONLINE 0 0 0 block size: 512B configured, 4096B native

errors: No known data errors

 

[SilverJS]

Here's another pic, with the whole System sub-part collapsed. Not sure if it looks any less alarming...?

http://imgur.com/LvVYcLx

 

[cyberjock]

Not sure, but creating pools named "raidz2" is a very very bad idea because the zpool commands themselves require stuff like "raidz2" when doing creation and such and so when you type the pool name is that because you are entering the pool name or because you are entering the vdev type?

I wouldn't be too surprised if something is throwing up because you've got a pool named raidz2, and when the .system dataset is supposed to be mounted on bootup that is going haywire because the command thinks that "raidz2" implies some kind of pool manipulation and exits with an error.

 

[SilverJS]

That would make sense. Thanks again for all your replies, much appreciated.

I did indeed read that in the documentation - three days ago. I didn't recall a warning of the sort during my research when I first set up the pool in 2011, but there was nothing about ashifts either back then...(not that I found anyway). This is all pointing towards my totally starting over, methinks, now that I have a reliable backup box.

 

[jgreco]

Not sure, but creating pools named "raidz2" is a very very bad idea because the zpool commands themselves require stuff like "raidz2" when doing creation and such and so when you type the pool name is that because you are entering the pool name or because you are entering the vdev type?

I wouldn't be too surprised if something is throwing up because you've got a pool named raidz2, and when the .system dataset is supposed to be mounted on bootup that is going haywire because the command thinks that "raidz2" implies some kind of pool manipulation and exits with an error.

Good point, created as bug 8898. https://bugs.freenas.org/issues/8898

 

[SilverJS]

Interesting. I suppose the limitation mentioned in the ticket didn't exist when I created my pool.

 

[jgreco]

I like how Jordan's dismissing it. Geez.

User has problem
Someone reports the problem
CTO says "that's not a problem"

Uh....kay.

 

[Bidule0hm]

Yeah, I saw that "so there's no such thing as a trivial fix to restrict user choices" you just need a lookup table and a if()... If I knew Python I would have done the fix already.

I more and more see that FreeNAS isn't really open source (even if it fits in the definition (well, more or less)) like the many other open source projects we know, I'm sad...

 

[depasseg]

In fairness to Jordan, I think he is saying that there isn't proof that this is the solution to the problem.

 

[Bidule0hm]

The problem is you can create pool/dataset/whatever that use names that aren't allowed by the ZFS specs (I know because I searched what are the allowed chars in the ZFS names before creating my pool) so the fix is just to add a blacklist of these names (and a regex for the forbidden chars if it's not already implemented), it's simple and it's the obvious solution to the problem (it's called input sanitization BTW) ;)

 

[depasseg]

I did a quick test, and it the regex is in there. I tried to create a pool named radiz2.

But the OP problem may have been caused because the pool was created prior to the 9.3 version (and I'm guessing the regex check).

 

[Bidule0hm]

Ok, so there is no problem actually, then the question is: how the OP created this pool?

 

[rogerh]

The problem is you can create pool/dataset/whatever that use names that aren't allowed by the ZFS specs (I know because I searched what are the allowed chars in the ZFS names before creating my pool) so the fix is just to add a blacklist of these names (and a regex for the forbidden chars if it's not already implemented), it's simple and it's the obvious solution to the problem (it's called input sanitization BTW) ;)

It is certainly a solution to a problem, but not necessarily the one discussed in this thread.

 

[Bidule0hm]

My post is obviously related to the bug ticket of jgreco's post, not to the original problem of the thread.

 

[jgreco]

It is certainly a solution to a problem, but not necessarily the one discussed in this thread.

Well, right. The poster has a problem that seems like it could be a side effect of this. He obviously has a poorly named pool, in part because FreeNAS allowed that. The intent of the bug report was to tighten that up for future users, not to try to solve the poster's issue.

 

[depasseg]

To me it sounds like the future pool creation issue is addressed. It sounds like there is an issue with earlier (9.2) versions allowing poor naming, which should be somehow be addressed during an upgrade to 9.3.

 

[jgreco]

Nice for someone to be thinking rationally about this.

 

[depasseg]

If only someone could create a bug to describe this issue....... ;-)