This is very true, and a very important thing to keep in mind. ZFS may be dubbed, "The end-all to all filesystems", but the operative word being "filesystems". The "scary" thing that you're pointing out here is that data. is. not. safe. ever. No checksumming or parity protection will protect my data from me doing "rm -rf" on the wrong target (I've done this a couple of times), mirrordir'ing the wrong way around (once), or the fire downstairs from spreading and devouring my precious magnetic platters (not yet) The example you're giving with it being happy to write out corrupt data, perfectly checksummed and stored "correctly" is an eye-opener to many users. Point in fact, a German guy on the zfs-fuse mailing list over the last couple of months who's experiencing concistent checksum errors being reported (as fixed) with each call to zpool status. Every scrub reports several checksum errors being fixed. Now, if that corruption is due to bad memory (or, to a lesser degree, on the controller-level), chances are a very large number of his files are wastebin material.

We have to keep that in mind, but be as that may, that's no reason not to pursue a solution that ensures integrity in its own domain. While any bad memory chip or controller or lightning can corrupt your data on any FS, in terms of data integrity ZFS is still the best solution at the moment.

Gonna take an easy punch and say that your point about "true archiving" is subject to exactly the same restrictions, being that any file has to exist in a filesystem But your point is good; no data is safe on any solution, so backups are the way to go. Preferably off-site, so that fire next week doesn't each your backup, too.



HFat is 100% right. ZFS is very new and does much more than other filesystems. There are lots of opportunities for something to go wrong. Have you used ZFS on a memory constrained system? Such as the likely case in a VM? If ZFS wants more memory than it can get it just crashes and takes the OS with it.

There are also no recovery tools for ZFS (fsck, chkdsk, etc). ZFS proponents claim it's unnecessary, but there are lots of horror stories on google to show that not to be true. Every filesystem can get corrupted, even ZFS.[/quote]

Seriously, people have to stop saying that. ZFS is running on year seven now, and it's not "brittle" at all. Any FS in its infancy will result in lost data. In ZFS's case were you could previously see it destroyed by a simple power loss - release versions, mind you, well that's just unforgivable. But this was resolved long ago, yet the horror stories still remain on the internet, as they should. But we should judge an FS by its current state, not its history.

About the memory issues; yes, I experienced that quite a few time with previous versions of ZFS-FUSE, but it never took down the system. It took down several FSes which could not be mounted, but without data loss, and it was resolved in the next version.

Of course, it there's not enough memory to sustain the FS that your system resides on, then any system will go down in flames eventually, but that would go for any FS. Yes, ZFS uses more memory than simpler filesystems, which is to be expected as you get snapshotting, dedupping, compression, checksumming and parity protection which isn't available in other FSes. Still a point to make, I agree, if your resources are low. In that respect, ZFS is definitely not the end-all filesystem. Wouldn't run it on my android, that's for sure

I hear you, and I'm not arguing against ZFS for this purpose. ZFS is fine for dealing with drive failures *on dedicated hardware*. ZFS or not, a non dedicated VM is just another possible point of failure. ZFS specifically needs buttloads of RAM not only for performance but for reliability. How much RAM do you have to give to a VM? If you really must go the VM route then MD on Linux or GEOM on FreeBSD (such as FreeNAS) are much better options just for the low RAM usage.

Since you you are on Windows your best option is to get a proper RAID controller that supports RAID5. However, it doesn't have to be expensive. Unless your system is AMD based, a motherboard with Intel ICH/PCH RAID does everything you want, including capacity expansion. And unlike most other "fakeraids" the Intel one performs very well. If you don't have the budget for a real RAID card Intel onboard is by far your best option if your OS is Windows.

FreeNAS is a good option and works well. As I said above, if you are using it in a VM or other memory constrained space then use GEOM. If you have the budget and space for a dedicated box with enough RAM then us FreeNAS with ZFS.

Domb, if you're going with an mdadm solution in virtualized Linux, I recently set up my system to deliver mail warnings using my GMail account. Might be useful:
http://danielsmedegaardbuus.dk/2010-10- ... ding-mail/

Why should people stop saying that? The fact that ZFS has no repair programs is true, and that is a very scary fact. ZFS may have improved but it is not perfect, nothing is. ZFS can still screw up and corrupt itself and it will always be that way, it will never be 100% foolproof. ZFS may (I'm not claiming either way) be more resillaint to FS level corruption, but having no repair tool and claming it is not needed is just downright arrogant.

Also, if you want to judge ZFS "by its current state" then it looks very bad. It is controlled by a very questionable company now (Oracle) and it's future is anything but certain. That alone would give me pause.


Let me clarify. FUSE because it is userspace cannot (at least should not) crash the OS. It will still kill your filesystem dead if it runs out of memory. Where ZFS will kill your OS is when it is in kernel space, like it's traditional home of Solaris or on FreeBSD. Running your FS in kernel space of course gives better performance.

The difference in memory usage between ZFS and other filesystems isn't just that it needs more. Of course ZFS needs more memory for the features it offers, and I'm not complaining about that. The issue is that ZFS does not share the normal OS features that other FS do such as disk cache. ZFS does almost everything itself, including caching. It does not know about or care how the OS manages memory. It just tries to take what it wants and dies if it can't. In other words, it doesn't play nice with the rest of the OS and use reasonable limits given the resources available. It's like a little kid who can't share, and when told it has to it takes its ball and goes home.

ATM, I'm doing a recursive par2/sfv creation run on a bunch of downloads + having downloads at ~3MB/s writing to my pool. ZFS has a working set of 6.6% of 4GB, i.e. about a quarter gig of mem. That is much for a filesystem (even when under fuse), but not really "buttloads", unless you're very skinny



Intel has worked very well for me, too. Did you mention earlier that you're using ICH9R? That does support RAID5, although you need an ICH10R to be able to expand your array. If anything, I'd say stay far away from SII3114-based cards. They're cheap, and when in non-raid they work great, but when in RAID... My experiences haven't exactly been great.

That's not a really stressful situation. Yeah, ZFS can often sit at relatively low memory usage if you are not using it much. The problem is when ZFS decides that it needs more. If your system doesn't have more to give it then it dies. If it could guaranteed that ZFS would run reliably in 256 MB then there would be no issue. But such a guarantee is impossible. 4 GB is the minimum I would give a ZFS system and only if it was dedicated. 2 GB might get away for a lightly used system. Even 2GB is insane for a VM that is used just for local storage.

The more files you access in a short amount of time seems to drive it up. Ironically, doing a backup to/from a ZFS filesystem will often cause it's memory usage to skyrocket since lots of files are being accessed.



Not to just be contrary, but I'm quite certain the ICH9R supports expansion. The ICH10R/PCH are just a bit faster.

I don't believe it is. For "repair", you have zfs scrub. For catastrophic destruction in metadata, you roll back to the most recent snapshot. This is a pretty good point, and I don't believe it's arrogant, it's just a completely different design:

http://docs.huihoo.com/opensolaris/sola ... html#gbbyc



1) The "bringing down your OS" issue is not an issue with the FS, if you lose the system fs, regardless of type, any live system will enter a really bad place. If losing a non-root fs can bring down the kernel, then it gets grey whose responsibility it is, the kernel developers (should the kernel oops or crash?) or the module developers (how gracefully do we die? do we die with the module or do we shed resources? and which is, in any event, the most sane thing to do?). You're probably right that I have an extra safe-guard with the FUSE layer, but I still haven't lost any zpool at any time, even with this somewhat questionable port in userspace. So even if an out-of-memory bug still exists in ZFS, it killing your system would be an extreme corner-case experienced at a moment where it's just a question of what would bring down the system, wouldn't you agree? And even then you can still expect your data to be safe after a reboot.

2) The octopus design of ZFS with it taking responsibility for things that are normally left for other layers to deal with (like caching) is, in my book, also "not pretty". But apparently it makes for one hell of a performer. ZFS also doesn't seem to mind when it cannot control such things (like with zfs-fuse), as my babel tower of partitions with md arrays with partitions with zfs members may impact performance, but none of my attempts to corrupt the pool or fses have succeeded. So cache or no cache, integrity is preserved. Not array integrity, but filesystem integrity.

In short, you have political and aesthetical points that I subscribe to as a developer, but functionality-wise, I cannot agree.

Sorry to have to run out on this now, but it's about supper time, guests are coming, I haven't freshened up yet, and there are still dishes to do Gonna check back tomorrow or later tonight, if I don't just dive into bed.