8.0.4 coming soon...

[gcooper]

Sorry for the quick double post, but what I did was yanked the silly artificial ceiling for vm.kmem_size_max that was tanking performance, so that the kernel allocator will work like it did before create larger sandboxes for UMA zones (I reread the kernel code in sys/kern/kern_malloc.c and better understand what's being done there now).

William is helping me out with getting the iX 'autotuner' script in trunk so it does the right thing as far as writing to the database is concerned. The previous version was "ok" from an integration perspective: it could be called from the command line and it touched /boot/loader.conf or called sysctl(8), but it didn't really hook into the database so values weren't visible via the GUI (and that's ultimately what we're driving for so people can tune their performance properly like with zfskerntune).

I'm seeing what can be done with William to get things in better shape for 8.2.0, but if people can bear with setting vfs.zfs.arc_max to a sane value (or I could remove it because you guys are running v15; v28 is the one that it really needs to be turned on for because to work around a potential scaling issue with dedup, etc...) to get ludicrous speed, either resolution would be fine with me.

I apologize that it took so long but I've been swamped with validating a driver at iX along with other things I've been working on for 8.2.0 (including toying around with shell scripts :P). Speaking of which.. if all goes well, I'll talk with delphij and see what we can do about upgrading mps in FreeNAS 8.2 (the newer driver is a lot more reliable than the current one is and possibly faster as well -- have been hammering the boxes, haven't run performance deltas yet between the two versions). It would have been nice to get it into 8.0.4, but it's late enough in the game that I think that it wouldn't be a good idea for that release.

 

[dbuurman]

Let's not rejoice too early; looks like the mrtg graphs on the monitoring page won't render, will investigate tonight but any pointers are welcome!

 

[gcooper]

Let's not rejoice too early; looks like the mrtg graphs on the monitoring page won't render, will investigate tonight but any pointers are welcome!

Did you accidentally flip architectures? What happens if you try running python /usr/local/bin/graph.py ?

 

[dbuurman]

Yeah, I accidentally downloaded the x86 iso. Tried the webupdater out of curiosity, and upgraded to x64.


Fresh install recommend?

 

[gcooper]

Yeah, I accidentally downloaded the x86 iso. Tried the webupdater out of curiosity, and upgraded to x64.

Fresh install recommend?

Doh ><. You should be able to just upgrade via the GUI to x64...

 

[joeschmuck]

Try removing this line from /etc/crontab and then restart crond:
*/5 * * * * root /usr/local/bin/python /usr/local/www/freenasUI/tools/alert.py > /dev/null 2>&1

I removed this line, it didn't help. I stopped CRON all together and no help. The drives are still spinning. I even went so far as to issue the command ataidle -I 10 /dev/ada0 (and to all my drives) but they never spun down even after almost 2 hours. I'm not sure why they are spinning. I have disconnected the network cable to the box just to ensure there isn't something polling the network and keeping the drives up. It didn't help. I'll start a new thread for this problem since I'm running 8.0.3-MM and I don't want to take over this thread with this problem.

 

[dbuurman]

Did you accidentally flip architectures? What happens if you try running python /usr/local/bin/graph.py ?

Code:

[root@sc440] ~# python /usr/local/bin/graph.py
Traceback (most recent call last):
  File "/usr/local/bin/graph.py", line 468, in <module>
    GenerateCpuGraph()
  File "/usr/local/bin/graph.py", line 189, in GenerateCpuGraph
    'GPRINT:avg4:LAST:%5.2lf Last\l',
rrdtool.error: This RRD was created on another architecture

Captain Obvious to the rescue... So, should I just reinstall or could this situation be benificial for bugfixing? @gcooper, regarding your comment above I asume what I did (BETA2_x86->RC1_x64) _SHOULD_ be possible? If I can be of any help please let me know.

 

[Ico747]

I updated from 8.0.3_P1_x86 to 8.0.4_BETA2_x64 with CD. Same problem with usr/local/bin/graph.py. Shouls I do a fresh install?

 

[William Grzybowski]

You can delete /data/*rrd*, /var/db/collectd and restart collectd daemon and all should be well (ofc w/o previous graphs)

 

[Ico747]

Tank you! It works.

 

[gcooper]

Tank you! It works.

I'm thinking that the branding needs to be changed, or the sorting needs to be changed such that people stop installing x64 instead of x86, and the converse. I knew this was going to happen going from amd64 -> x64 and i386 -> x86 (it's only 2 characters different).

Would this be ok?

x86 -> x86_32
x64 -> x86_64

This is more pedantic (it's what gcc is taught to do in several cases on Linux), but maybe this is what we need in order to close this branding confusion loop once and for all.

 

[joeschmuck]

I removed this line, it didn't help. I stopped CRON all together and no help. The drives are still spinning. I even went so far as to issue the command ataidle -I 10 /dev/ada0 (and to all my drives) but they never spun down even after almost 2 hours. I'm not sure why they are spinning. I have disconnected the network cable to the box just to ensure there isn't something polling the network and keeping the drives up. It didn't help. I'll start a new thread for this problem since I'm running 8.0.3-MM and I don't want to take over this thread with this problem.

This problem only appears in my 8.0.3-MM installation and does not occur with 8.0.4-MM. Problem solved, or should I say it just doesn't matter and I must have done something to 8.0.3-mm to cause it (I hope).

 

[gcooper]

This problem only appears in my 8.0.3-MM installation and does not occur with 8.0.4-MM. Problem solved, or should I say it just doesn't matter and I must have done something to 8.0.3-mm to cause it (I hope).

8.0.3 or 8.0.3-p1 ? This is important because 8.0.3-p1 updated the version of ataidle per the upstream maintainer's recommendation :).

 

[dbuurman]

I'm thinking that the branding needs to be changed, or the sorting needs to be changed such that people stop installing x64 instead of x86, and the converse. I knew this was going to happen going from amd64 -> x64 and i386 -> x86 (it's only 2 characters different).

Would this be ok?

x86 -> x86_32
x64 -> x86_64

This is more pedantic (it's what gcc is taught to do in several cases on Linux), but maybe this is what we need in order to close this branding confusion loop once and for all.

Much clearer imho!

 

[ProtoSD]

I'm thinking that the branding needs to be changed, or the sorting needs to be changed such that people stop installing x64 instead of x86, and the converse. I knew this was going to happen going from amd64 -> x64 and i386 -> x86 (it's only 2 characters different).

Would this be ok?

x86 -> x86_32
x64 -> x86_64

This is more pedantic (it's what gcc is taught to do in several cases on Linux), but maybe this is what we need in order to close this branding confusion loop once and for all.

It doesn't seem like a problem to me as long as the AMD users don't get confused :)

 

[gcooper]

It doesn't seem like a problem to me as long as the AMD users don't get confused :)

ROFL. Yeah.. it's not going to happen right away. It needs a more in-depth discussion and we need the dust to settle from the last rename first :).

Just for reference dbuurman, how did you update your system (via the GUI or via CD)? There's a gap that's existed for a while being able to switch architectures in upgrades that might get some love in the near future ;)..

 

[dbuurman]

Just for reference dbuurman, how did you update your system (via the GUI or via CD)? There's a gap that's existed for a while being able to switch architectures in upgrades that might get some love in the near future ;)..

The (x86/i386) BETA2 was the result of a fresh CD install, which was then in turn upgraded trough the GUI to FreeNAS-8.0.4-RC1_MULTIMEDIA-x64 (10231)

 

[joeschmuck]

I'm thinking that the branding needs to be changed, or the sorting needs to be changed such that people stop installing x64 instead of x86, and the converse. I knew this was going to happen going from amd64 -> x64 and i386 -> x86 (it's only 2 characters different).

Would this be ok?

x86 -> x86_32
x64 -> x86_64

This is more pedantic (it's what gcc is taught to do in several cases on Linux), but maybe this is what we need in order to close this branding confusion loop once and for all.

To be honest I think you should keep the same naming convention you have established. If you are going to change it and use that naming convention, I'd add "_bit" to it so it reads "x86_32_bit" or "x86_64_bit" because if it doesn't say "bit" they won't understand if it's 86 bits, 32 bits, 64 bits. Someone will not know what "x86" means so you might as well drop it. But wait, a few weeks from now someone will ask if this is for an i-7 or ATOM processor so you should list all compatible CPUs.

You get where I'm going. Someone will not understand the naming convention you choose and it will happen. I personally like the current naming convention but I'm not opposed to anything you make it as I will figure it out like most of the users here. Also, isn't this in the Read Me First posting?

-Mark

 

[joeschmuck]

8.0.3 or 8.0.3-p1 ? This is important because 8.0.3-p1 updated the version of ataidle per the upstream maintainer's recommendation :).

FreeNAS-8.0.3-RELEASE_MULTIMEDIA-p1-x64 (9591)

I assume 8.0.4-MM Beta2 has the same version but it does work for me just fine. Maybe it was a build issue? I don't want to point fingers here because it could have been something I did to myself. I don't feel like reloading 8.0.3 just to test this out. It's my real NAS and I'd like to minimize messing with it.

EDIT: The error I'm having must be something I did and is no way the FreeNAS software's fault. I don't know what I did but I'm sure I did it.

EDIT #2: The problem was associated with my config file somehow. I was able to restore to original configuration and then load a saved configuration and it works great. Not sure what happened at all.

 

[jpaetzel]

8.0.4-RC1 is available for download, give it a spin and report any problems, preferably by creating a ticket at http://support.freenas.org with the version set to 8.0.4-RC1, at this point the 8.0.x branch is fairly mature and it's like 8.0.4-RELEASE will appear very shortly.

https://sourceforge.net/projects/freenas/files/FreeNAS-8.0.4/