ZFS superior to UFS for desktop / workstation use?

Strange. With the same error messages (except: "Enclosure added: encl=0" because the controller dont have that feature) you post, a 9550SXU-4LP of mine died some days before, crashing the whole system even if no system files where on it. It performed well for 2 years and 11 months under FreeBSD 7.x, so it is still under warranty and LSI will replace it, :D .
 
User23 said:
Strange. With the same error messages (except: "Enclosure added: encl=0" because the controller dont have that feature) you post, a 9550SXU-4LP of mine died some days before, crashing the whole system even if no system files where on it. It performed well for 2 years and 11 months under FreeBSD 7.x, so it is still under warranty and LSI will replace it, :D .
Did you update your kernel just before that started happening?

It looks like LSI submitted the patch I mentioned in my earlier reply: kern/149968
 
rusty said:
Not so, 4GB is the recommended amount if you want to enable prefetching, ZFS is still perfectly usable with less. It will just need some tuning, that's all.
As i understand, even with 4GiB physical RAM you would still have prefetching turned off by default. If i'm not mistaken, it detects of 4GiB of available memory, but things like the kernel lower the amount of available memory straight away.

So in reality you might need 6GB+ for prefetching to be enabled by default. As i understand this was done because otherwise prefetching would use up alot of memory and hurt performance in some cases instead of aiding it.

User23 said:
Yes, i was wrong. GPT solve this.
Or just use no partitions at all. No real reason you need them if you're not going to boot from them or needing cross-OS compatibility. A geom_label attached and using that instead, with no partition underneath, would avoid any alignment issues or partition limitations.

The new GPT support in FreeBSD seems nice though, especially as it can also label (/dev/gpt/disk0 for example). But i do not like it requiring geomflags in some cases and saying the GPT label is corrupt whenever you enlarge the device. I hope it gets improved further in this regard.
 
Terry_Kennedy said:
fsck-ing a 2TB UFS partition takes quite some time. Even when [r]dump takes a snapshot, it takes some time. That's something to consider when building large partitions.

Not when it's a gjournal'd, I don't have a UFS volume that big, but I'd estimate it would be done in under 3 min provided decent disk speed. SU + J should be here soon as well which eliminates that problem.

FWIW, gjournal also improves IO on heavily multithreaded access, but will decrease performance on single threaded access.
 
Terry_Kennedy said:
Did you update your kernel just before that started happening?

It looks like LSI submitted the patch I mentioned in my earlier reply: kern/149968

No, i did not change the kernel before and a new controller fixed the problem. The array had/has a UFS on it. After replacing the controller i was able to reproduce the error on another machine with FreeBSD 8.1 continously without heavy io load.

But the patch is very interesting. Hopefully this may fix the problem i had with the "Unexpected status bit(s)"

thx
 
Back
Top