Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Though Jeff is indisputably the father of ZFS, the ZFS team was (and is) much larger than Jeff. Many of the ZFS team (including its co-inventor, Matt Ahrens) are now at Delphix [1], and continue to be very active in the ZFS community[2] via illumos, its repository of record[3].

[1] http://www.youtube.com/watch?v=-zRN7XLCRhc#t=46m45s

[2] http://blog.delphix.com/matt/2011/11/01/zfs-10-year-annivers...

[3] http://blog.delphix.com/matt/2012/07/11/performance-of-zfs-d...



Bryan, what's your opinion re: the stability of the LLNL port of ZFS on Linux? The 0.6.0 release is apparently just around the corner and several high-profile people in the community, Russell Coker for one [1], have started using this on production systems. I'd love to make the move to ZFS as well but am still afraid of data loss. I started using XFS on Linux in 2002 and my gut feeling is that ZFS on Linux is now at or around a similar point of maturity. If you could share your opinion I'd be really grateful. Thanks so much.

[1] http://etbe.coker.com.au/2012/07/31/zfs-debian-wheezy/


I haven't used the LLNL port myself, but I would be shocked if it were not rock-solid. First, ZFS (unlike, say, DTrace) has reasonably limited dependencies on broader system implementation; you don't have to port other subsystems to get ZFS working. Second, even where it does have external dependencies, it can operate remarkably well when they're not functioning: because of its indirect checksums, ZFS can operate correctly (or at least, non-fatally) in the presence of nearly byzantine behavior from the I/O subsystem. Third, of the ZFS issues I've seen and helped debug over the years (and my data has been on ZFS as long as just about anyone's), none have manifested themselves as data corruption or (in the absence of physical failure that exceeded the redundancy of the pool) data loss. Finally, of these issues over the years, virtually all were fixed inside of ZFS itself -- there was no platform specificity to either the problem or the fix. (The exceptions being platform-level I/O issues that resulted in pathological performance -- but it's hard to call those ZFS issues.)

tl;dr: absent glaring port issues, ZFS on Linux is or should be at maturity of ZFS itself -- which is to say, very mature.


Brian - if only a few enthusiast users can use Solaris derivatives on their hardware, do you not think ZFS is just relevant for the Enterprise folks? Are any ex-Sun,Oracle people putting in efforts for more X86 hardware compatibility?

To me, ZFS and Dtrace are of no consequence if I can't use them on my own hardware. And I am sure there are many more people like me.


Virtually all of the work that we do in the illumos community is on x86 -- and not merely keeping it functional, but actively advancing the state of the art. For example, we at Joyent ported KVM to illumos last year[1], and since that time we have deployed many thousands of virtual (x86) machines into production on (x86) hardware running SmartOS, our illumos derivative.[2]

[1] http://lwn.net/Articles/459754/

[2] http://smartos.org/


I keep a tab on those but I was more talking about real desktop/laptop/workstation class x86 hardware, not VM.

I have tried and given up running Solaris derivatives on bare metal even if for running just command line. The hardware /peripheral support just doesn't seem to be there.


There is a simple way to guarantee that an Illumos distro works, and that's to use Intel for everything: chip, motherboard, nics, you name it.

Other setups can work, but you need to be very aware of this: http://illumos.org/hcl/


Doesn't FreeBSD include ZFS and Dtrace, and run quite well on x86 hardware?


>> To me, ZFS and Dtrace are of no consequence

>> there are many more people like me

Recently I was wondering how can there be so many tech startups around just now. Nothing under the sun is new so how can they cut a living?

Ive realised this attitude (which there is absolutely nothing wrong with) is the reason. The established players leave gaps for their own reasons and the little guy comes along and seizes the opportunity.

Skipping over cheaply accessible best in class technology, at a philosophical level at least, seems akin to pointing a 12 gauge at your toes.


I run OpenIndiana on a variety of different X86 machines, both AMD and Intel without issues. So far compatibility hasn't been an issue that I've ran into and the operating system and everything around it is rock solid.

Much better than the Linux machines that were replaced.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: