8.0.3 RELEASE coming soon

[survive]

Hi gcooper,

So what's going to be the performance impact of setting "vfs.zfs.arc_max" to 1024MB on a system that's running great out of the box right now? Currently my system returns "vfs.zfs.arc_max: 7228235776" on 8.0.2 AMD64 build.

Personally (and I don't mean to sound like an ass about it) I'd object to anything that going to cost me performance just to make FreeNAS work better on gear that doesn't meet the published minimum specs. That said, I think it would be worthwhile to include something like the "zfskerntune" extension (http://sourceforge.net/apps/phpbb/freenas/viewtopic.php?f=97&t=5881&hilit=zfskerntune) that daoyama wrote for FreeNAS 0.7.X to make tuning easier for everyone or perhaps there could be a "tuning" section added to the docs with some known good settings & clear instructions that users could add to cut down on the "I found some setting in a post somewhere that seem to work ok except for when I ...." problems.

Also, earlier in the thread I suggested bumping the image size from 2000MB to something like 3500MB. I didn't make the suggestion because I want to to add packages (I'm a strict the NAS is a NAS kind of guy), I made it because I see a lot of folks in the IRC channel having trouble because the current image is just a hair to big to fit on many 2GB USB keys. It would be equally effective to decrease the image size just a bit so it will be small enough to go on a 2GB key that's really 1.9GB. Currently I just advise them to get a 4GB key for $5.00 and it almost always resolves the weird boot problems they are seeing, but there is sometimes some grumbling about reality not matching the published requirements.

-Will

 

[gcooper]

So what's going to be the performance impact of setting "vfs.zfs.arc_max" to 1024MB on a system that's running great out of the box right now? Currently my system returns "vfs.zfs.arc_max: 7228235776" on 8.0.2 AMD64 build.

Performance will be reduced if you're pushing through a lot of traffic (there are some scenarios that we've seen in failure cases where the opposite is true though with ZFS and pools fail to import after 24 some hours of trying) -- but your box will not tip over in the field if ZFS gobbles up all your RAM, which is the first aim that I'm shooting for, and some things may improve speedwise because your RAM is free to do other things like act as scratch buffer space for packets, userland apps like samba, etc :).. what I'm ultimately trying to prevent or reduce is what I refer to as: "Gentoo syndrome". Gentoo Linux users back 7 years ago when the project was fresh and cool had a nasty habit -- me included when I first started using Linux -- to modify CFLAGS, LDFLAGS, etc based on some lofty idea that our compiles and runtime operations would go faster and everything would be kumbaya happy. A lot of times the compile/execution times weren't any faster (sometimes they were actually slower) and the problem was that some of the compile flags introduced unexpected and undesirable consequences because of toolchain bugs, how things were implemented at the architecture level, etc (-funroll-loops and the *math CFLAGS for instance were awesome, but I digress).

I'm all for things going fast, but I would rather someone who knew what they were doing be doing the tuning and for things to be harder to achieve for the general populace, because the problem is that while the community is great... I don't want to be at fault in the event that someone's storage array goes south because they misconfigured things thinking that they were going to go ludicrous speed with their storage when in fact the recommendation they received was incorrect.

So while I agree and I'll continue to work with guys like you, protosd, etc because I know you're technically capable.. I wouldn't want my parents to have to call me if their NAS storage goes south because more likely than not they're more worried about just saving their data in a safe and secure place than they are at getting it at 10GbE+ speeds [today] -- which some of us are *indeed* trying to achieve for various reasons. I'm programming safe defaults with people like my parents in mind because FreeNAS is targeted as an easy to use solution that people can just plop their files onto and not have to worry about the nitty gritty details behind running SMART tests, ZFS scrubs, etc :).

Personally (and I don't mean to sound like an ass about it) I'd object to anything that going to cost me performance just to make FreeNAS work better on gear that doesn't meet the published minimum specs.

No worries. There seem to be a lot more [vocal] people complaining about the fact that their old gear doesn't work on FreeNAS 8. Darned if I do, darned if I don't I suppose.. I'm trying to quell the shouting as best I can so I can get back to more pressing issues for the FreeNAS community, FreeBSD community, and also iX.

That said, I think it would be worthwhile to include something like the "zfskerntune" extension (http://sourceforge.net/apps/phpbb/freenas/viewtopic.php?f=97&t=5881&hilit=zfskerntune) that daoyama wrote for FreeNAS 0.7.X to make tuning easier for everyone or perhaps there could be a "tuning" section added to the docs with some known good settings & clear instructions that users could add to cut down on the "I found some setting in a post somewhere that seem to work ok except for when I ...." problems.

We could publish some guidelines, but the problem is that one size doesn't fit all (as I'm sure you're aware) and the applecart is going to get upset with plugins as the required footprint will no doubt perturb any recommendations or formulas that we could publish that would be of value. We're going to produce a foundation from which people can develop plugins and things with, but the fact is that we don't own the entire solution in FreeNAS (emphasize this as opposed to TrueNAS which we do create products based off of) like Apple does with the iPhone/iPad, Google does with its Android platforms, etc.

Also, while Daisuke's script works on 7, it most certainly doesn't work on 8 or 9, and some of the settings he's setting in the 'legacy' FreeNAS branch images aren't really smart for people that have smaller NAS deployments. I would be leery of using his script across port/package upgrades as well as footprints change (for better or for worse). It's a good first start/rule of thumb, but it's by no means the silver bullet that one might like it to be.

Also, earlier in the thread I suggested bumping the image size from 2000MB to something like 3500MB. I didn't make the suggestion because I want to to add packages (I'm a strict the NAS is a NAS kind of guy), I made it because I see a lot of folks in the IRC channel having trouble because the current image is just a hair to big to fit on many 2GB USB keys. It would be equally effective to decrease the image size just a bit so it will be small enough to go on a 2GB key that's really 1.9GB. Currently I just advise them to get a 4GB key for $5.00 and it almost always resolves the weird boot problems they are seeing, but there is sometimes some grumbling about reality not matching the published requirements.

Ok. It's something we definitely need to revisit (the whole 900MB vs 1GB sizing problem where some -- mostly cheap -- USB flash vendors lie), but I don't think right now is the best time. It might be a better idea to fix this in 8.2.1; ultimately what I'd like to see is a single image that's appropriately sized and gets dd'ed/tar'ed properly out to a set of GPT partitions (sized properly according to the destination media), because stuff right now is hacky / error prone as -- again -- USB device vendors sometimes lie about capacities (just like SATA drive vendors like lying about when data is _actually_ synced out to a disk).

 

[jgreco]

Hmmm.. is there a compelling argument for doing this (in particular, I don't have access to any network based UPSes)?

We could probably fix that, ya know. We have a stack of Smart-UPS's just sitting in storage doing nothing for nobody. PM me if you wish to discuss it.

 

[ProtoSD]

OH, one other fix that should be quick, stop collectd from stopping/starting in between each snapshot when deleting a group of snapshots.

 

[gcooper]

OH, one other fix that should be quick, stop collectd from stopping/starting in between each snapshot when deleting a group of snapshots.

I'll see about that -- thanks for the reminder ;)..

 

[gcooper]

We could probably fix that, ya know. We have a stack of Smart-UPS's just sitting in storage doing nothing for nobody. PM me if you wish to discuss it.

Sweet! Ok, I'll see what we can do for 8.2+ then!

 

[gcooper]

I'll see about that -- thanks for the reminder ;)..

Just checked, and this only affects trunk post-8.0.2+, so nothing that I need to do here :).

I think I'm going to call it a wrap and start the 8.0.3-BETA1 builds; in the meantime I'll keep on feverously working on imposing the sane system limits that exist on trunk, backport 'image footprint fixes' and the AD interoperability issue at boot (I'm close, but I need to run a day's worth of tests)..

 

[pierrep]

any chance the netatalk upgrade in release 8.0.3 will fix the ticket #763 (http://support.freenas.org/ticket/763) ?

'cause so far, AFP has not worked too great since 8.0.1... Meaning Time Machine is about in the same state.

can't wait to try it (after a good backup) anyway

 

[gcooper]

any chance the netatalk upgrade in release 8.0.3 will fix the ticket #763 (http://support.freenas.org/ticket/763) ?

'cause so far, AFP has not worked too great since 8.0.1... Meaning Time Machine is about in the same state.

can't wait to try it (after a good backup) anyway

Are you using Lion or Snow Leopard (I have both.. I just need to know what to test)?

Also, what permissions are you setting on your zpool/dataset and who are you logged in as?

 

[pierrep]

Are you using Lion or Snow Leopard (I have both.. I just need to know what to test)?

Also, what permissions are you setting on your zpool/dataset and who are you logged in as?

Still Snow Leopard

group "users" has Read/Write access on first dataset (no discovery)
"user1" has Read/Write access on second dataset (discovery "TimeMachine")

I'm accessing both datasets as "user1"

is that what you were thinking when talking permissions ?
thanks for the help

 

[gcooper]

Still Snow Leopard

group "users" has Read/Write access on first dataset (no discovery)
"user1" has Read/Write access on second dataset (discovery "TimeMachine")

I'm accessing both datasets as "user1"

is that what you were thinking when talking permissions ?
thanks for the help

Your permissions looks ok.

Going back to your ticket, what does the following command output?

find /mnt/datastore -name .AppleDesktop | xargs find

 

[lyzanxia]

Just inquiring:
Is the proper detecting & alerting in case of losing a disk, still on the roadmap? And making replacing a disk thru gui foolproof?

 

[gcooper]

Just inquiring:
Is the proper detecting & alerting in case of losing a disk, still on the roadmap? And making replacing a disk foolproof?

1. UFS - not sure; I'm pretty sure that this reporting doesn't exist (should, but it doesn't).
2. ZFS - yes, depending on the controller.
a. We have mps stuff working internally, but for various reasons (mostly policy control and the fact that it'll be tweaked according to the configuration and models we define at iX), we can't really release it.
b. mfi works (sort of), but it's currently setup to only do daily reports.

The alerting support that exists in FreeNAS/TrueNAS currently is a stopgap feature. Alerting and logging will need to be cleaned up in future releases; I have some ideas how it should be done to be more generic and tunable.

 

[Athanasios Kakargias]

Just for the record, an APC Smart-UPS 750, could not connect neither with the usb driver/ neither with the apcsmart on the serial port. I kept getting connection refused the usb driver responded that my device is not yet supported? (retelling from memory as I don't have it handy right now)

So one more vote for NUT upgrading (however not sure if it will solve my problem :)

 

[ProtoSD]

Gcooper,

I just took a quick look at Beta-1. I'm wondering if the Tuneables could be setup like the Auxiliary parameters for Samba? I know it would take me awhile to enter my list one at a time. It would also make it easier to comment something out if you wanted to test a change.

I haven't had a chance to look at much else right now, time to get some sleep!

 

[gcooper]

Gcooper,
I just took a quick look at Beta-1. I'm wondering if the Tuneables could be setup like the Auxiliary parameters for Samba? I know it would take me awhile to enter my list one at a time. It would also make it easier to comment something out if you wanted to test a change.

When the feature was designed 2 months ago, Josh and I purposely asked William to set things up like this to sanitize the input and avoid potential issues with someone forgetting a quote and their box would be bricked on next boot.

I haven't had a chance to look at much else right now, time to get some sleep!

Feel ya there ;)...

 

[alexwill22]

Just for the record, an APC Smart-UPS 750, could not connect neither with the usb driver/ neither with the apcsmart on the serial port. I kept getting connection refused the usb driver responded that my device is not yet supported? (retelling from memory as I don't have it handy right now)

So one more vote for NUT upgrading (however not sure if it will solve my problem :)

I have the same issue as well with both
APC Smart UPS RT 2000 - SURTA2000XL
APC Smart UPS RT 1500 - SURTA1500XL

The driver refuses them both for serial and usb.

 

[gcooper]

Just for the record, an APC Smart-UPS 750, could not connect neither with the usb driver/ neither with the apcsmart on the serial port. I kept getting connection refused the usb driver responded that my device is not yet supported? (retelling from memory as I don't have it handy right now)

So one more vote for NUT upgrading (however not sure if it will solve my problem :)

Release notes suggest that going from 2.4.2 to 2.4.3 fixed USB interoperability issues. That being said, unless someone can test out a FreeNAS trunk image and verify whether or not things are truly fixed I'm not convinced that upgrading NUT will actually improve things as I don't have the hardware in-house to verify the new version with.

If it does fix things, then I'll upgrade NUT and net-snmp (dependency) -- but this along with anonymous bind with ldap are the last items that need to go into 8.0.3. After that I'm drawing a line in the sand, test, test, test, and start rolling things up into an RC. If all goes well I'm hoping for a release either by the end of this week or early next week.

 

[ProtoSD]

When the feature was designed 2 months ago, Josh and I purposely asked William to set things up like this to sanitize the input and avoid potential issues with someone forgetting a quote and their box would be bricked on next boot.

I can understand the need for error checking, but what if you want to edit an entry? Sorry, I still haven't tried it, I just saw your reply. I just have quite a few entries and entering them will be one thing, but commenting them out/disabling something/editing them will be another. I think it might need adjusting.

Also, people need to be warned before upgrading that their existing tuneables will get wiped unless you have a method for importing them into the new system?


Edit: ok, I properly tested it and I see how the editing works and it's fine. I still think multiple entries is a hassle and warning/importing tuneables before upgrading to 8.0.3 should be done.

 

[ProtoSD]

I just tried to import a 1GB NTFS formatted flash drive with Beta-1 and got "An error occurred while labeling the disk.".

I'm not sure if you've done any work on this, but in case you have or plan to, I thought I'd let you know it's still broken.

I also tried manually loading /usr/local/modules/fuse.ko and then doing the import again and got the same error.

I don't understand, I thought my workaround for loading fuse.ko was working before. I had/have a ticket opened for this and MSDOSFS since before 8.0.1?