Slashdot Mirror

Yes, no one would suggest ZFS as the filesystem for your phone. You might have to do things like disable checksums if you have an older or otherwise underpowered CPU, and it's tuned by default to use memory quite heavily. That anecdote isn't very relevant for today's desktop or server environments though.

I was benchmarking internal disk to disk transfers, and the system really took a bit over 6 Gigabytes. The memory usage pattern was somewhat of interest, as it ramped up for some time until releasing, and the cycle was restarted. The default of ZFS seems to be that all of the system memory is used except 1GB: http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Memory_and_Dynamic_Reconfiguration_Recommendations

From Freenas Hardware reqs: "The best way to get the most out of your FreeNAS hardware is to install as much RAM as possible. If your RAM is limited, consider using UFS until you can afford better hardware. ZFS typically requires a minimum of 6 GB of RAM in order to provide good performance; in practical terms (what you can actually install), this means that the minimum is really 8 GB. The more RAM, the better the performance, and the Forums provide anecdotal evidence from users on how much performance is gained by adding more RAM. For systems with large disk capacity (greater than 6 TB), a general rule of thumb is 1GB of RAM for every 1TB of storage. "

Instead of FUSE + ECC, you could try ZFS Checksums.

I'm curious why you create a new directory tree every three months, instead of just continuing to link to the old one? (I'm assuming you're using hardlinks and running rsync with --link-dest). I just link to my old tree and periodically purge old "copies". For instance, I might keep the last 7 days, but then only 2 weeks before that, and maybe quarterly before that.

I thought that was the beauty of hard links... that you could remove the oldest "full" file, but as long as you have at least one link to it, the data will remain. Am I missing something by not recreating my tree?

"One can be infinitely fast, if correctness is not required."

If one looks at that thread, it digresses into the extreme, talking about one's flatmate and discussions on restaurants...

Besides, it was posted back in May, and about ZFS on FreeBSD... the version on Solaris and OpenSolaris has progressed massively since then.

For information from "the horse's mouth", so to speak, here is some interesting reading:

http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide

The fact that no one has refuted it can be seen as proof enough that the claim is so preposterous as to render such preposterousness self-evident and therefore unworthy of refutation. Additionally, your ability to receive intellectual "hand-outs" is stymied by said lack of refutation. Ergo, your desire for more information will go unfulfilled. However, being the bleeding-heart that I am: http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Memory_and_Swap_Space and, for future reference, http://www.google.com/

a good place to start is probably the ZFS Best Practices page. the google text cache of that page is here. beyond that, try to google "zfs ram requirements".

I don't work for sun but I've been playing around with zones a bit and found a lot of useful information on zones. Haven't looked into dtrace much but I did find some good references online. Google for one line dtrace scripts as a start.

As for zones. I found this page useful for describing sparse root and whole root zones and how to implement them. Before I really understood what I was doing I had a zone running.

http://www.solarisinternals.com/wiki/index.php/Zones

RAID doesn't open you up to data loss from accidental deletion, it just doesn't help prevent it. ZFS, however, does. You can check it out on FreeBSD (which has much better SATA controller support than OpenSolaris).

Although FreeBSD 7.0 (the version with ZFS) is still in Beta, it's been in a feature-freeze for a long time, and it's generally rock-solid. Just read the ZFS guides from OpenSolaris and the tuning guide for FreeBSD:

http://wiki.freebsd.org/ZFSTuningGuide
http://docs.sun.com/app/docs/doc/819-5461
http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide

Note that ZFS really wants to be run on a 64-bit OS, and it wants a lot of RAM. If you've got that, though, it's fantastic, and it allows for easy snapshots (which helps protect against accidental deletion.)

http://www.solarisinternals.com/wiki/index.php/ZFS _Best_Practices_Guide#Memory_and_Dynamic_Reconfigu ration_Recommendations

is a good place to start looking, but as you can see here:

http://www.opensolaris.org/jive/thread.jspa?messag eID=122983

You can use the command located here:
http://milek.blogspot.com/2006/09/how-much-memory- does-zfs-consume.html

to show how much is being consumed by ZIO buffers.

Yes, pretty much. Raidz2 is a type of element of the pool, not 2 raidzs. So you can lose at most two drives from each raidz2 component and be ok (the mean time between data loss is very good for double parity).

Mirror is of course the best in terms of both speed and reliability. ZFS supports N-way mirrors (multiple 3 way mirrors has a very high MTDL)

http://www.solarisinternals.com/wiki/index.php/ZFS _Best_Practices_Guide

Something like ZFS, that "touches so many other applications and parts of the OS" has to be the default. Otherwise you have to support two completely different ways of using the system.

Perhaps you haven't heard of the VFS? (A fine paper, by the way, well worth the read.)

Supporting multiple filesystems is required in this case; users will not accept having to completely rebuild all their filesystems in order to use them under a new OS version, especially if doing so makes those filesystems inaccessible to earlier versions. "Default" in this case probably just means "default for newly created filesystems".