Do you have any details you can share here? It doesn't go into scaling deficiencies in GNU/Linux NFS clients or defects in popular GNU/Linux filesystems either:
www.softpanorama.org/Articles/Linux_vs_Solaris/comparison_of_internal_architecture.shtml
But it is a useful guide for those of us who recognize that there are applications where Solaris is a better fit and there are other applications where a GNU/Linux dist is a better fit. I haven't met anyone who has used ZFS, understood it and still shares your opinion. In my opinion, the only thing Sun's marketing might be guilty of is focusing on catchy and confusing names for technology and not enough on explaining how unique and useful the technology is. As I write this, I'm transfering my DV video and photos from an HFS+ volume to a ZFS pool. I'm looking forward to the day when Apple, Linux and Microsoft have a filesystem which can raid, resilver and compress as easily as ZFS and which can validate that what I read from disk is what I wrote. Regardless of what name marketing comes up for these features, I doubt I'm the only one who finds them useful.

Posted by bnitz on May 24, 2006 at 11:33 PM GMT+00:00 #

1) just compare Linux VFS and Solaris VFS. Solaris one is a mess 2) due to this Solaris UFS is race in ufs_rename() 3) I have read about ZFS, including on-disk structures paper. and I definitely can say that: a) 256 _bytes_ block pointers suck b) if you change a single byte, you need to rewrite and re-calculate checksum of several blocks, which can be very large. this also suck 4) instead of packing all _unrelated_ things into a single one as ZFS does, I hope Linux will just get a good API to ask raid for recovery of given block

Posted by 81.22.216.253 on May 25, 2006 at 08:31 AM GMT+00:00 #

If Linux VFS is so wonderful, how come the unionfs guys are having such a horrid time fixing all the corner cases?

Posted by jmansion on May 25, 2006 at 10:06 AM GMT+00:00 #

mamamia, The ufs_rename race was fixed as of Nevada Build 25 you should see it in Solaris 10 update 2. I'm not a ZFS expert so you might want to post your comments and criticisms on one of the ZFS forums or blogs. Nothing I've seen from userland suggests that "256 byte block pointers suck", and if you want ZFS checksumming to behave as it does on other filesystems, do this: zfs set checksum=off {pool name}

Posted by bnitz on May 25, 2006 at 11:30 AM GMT+00:00 #

I'd hoped this document would help people become familiar with linux and Solaris. I try to avoid tool zealotry. Yes, the rename race was a bug. There are also bugs in GNU/Linux. I have some 40G drives which mysteriously stopped working and are no longer partitionable or detectable by BIOS immediately after ReiserFS/Kernel 2.6 synced them. I have 2 USB memory sticks which seem to have been killed by this Linux problem and I'm familiar with the 2.6 kernel's ability to destroy certain CD-ROM drives.

If your understanding of ZFS is based on the marketing material, then maybe the material is incorrect. Have you trie downloading Solaris express and benchmarking ZFS against your favorite filesystem? Try ZFS with checksumming on and off. Even if MD5sums were calculated all the way back to the root block for a 1 byte change (they aren't), why should you care if it performs? If you took any other existing filesystem and made the checksum granularity, inode and block pointer size precisely what you consider to be ideal, it would still be missing most of what makes ZFS a well designed filesystem. As a user I don't even care about these parameters as long as I don't bump into the 64k, 640K, 504M, 2G, 8G, 32G, 127.5G... barriers. I'm more interested in the fact that I can just buy another hard drive, add it to the pool and immediately increase the storage in that pool.

Posted by bnitz on May 27, 2006 at 12:25 AM GMT+00:00 #

So you have a process which modifies several thousand files a second and writes > 1GB/s and it's CPU bound? This is unusual but it might be a good case running zfs set checksum=off {pool name}. You'd be no worse off than with other filesystems which never checksum all data.

I don't think Linux LVM would allow you to grow a single drive to a RAID1. It certainly wouldn't let you do it online and you would have the extra step of increasing the filesystem size to match the new pool and praying that it works. With ZFS it's just a matter of typing zpool add {pool name} {drive}. LVM wouldn't give you clones or rollbacks either.

Posted by bnitz on May 27, 2006 at 11:48 AM GMT+00:00 #

I didn't say >1GB/s is unusual for Solaris I said > 1GB/s CPU bound is unusual, and it is for any X86 OS until disks and I/O bandwith improve by an order of magnitude or two.

I'm trying to figure out what kind of hardware/os combination you're using. XFS seems to plateau at about 0.5GB/s, EXT3 is worse. EXT2 might be faster, but its lack of journaling and reliable cache flushing makes it unworthy of enterprise class. You don't sound like a Niagara enthusiast. You sound savvy enough to not be fooled into thinking that cache writes == writes and you certainly wouldn't confuse the time of an LVM2/ZFS snapshot with the time to replicate a volume's data. We could compare theoretical deficiencies in ZFS with a theoretical filesystem all day, but I'd like to see some specifics and numbers. I'll be happy to file a ZFS performance bug when I can demonstrate that it is real.

As I said, "LVM wouldn't give you clones or rollbacks either", yes LVM2 can do snapshots, but it doesn't seem to include clones or live rollback capability. Does it allow you to mount a live snapshot? Here are some differences between ZFS and Linux+LVM+Raid.

I doub't I've read as much ZFS marketing material as you have. I learned about ZFS from bloggers (most of whom aren't Sun employees), from man pages and from using it.

Posted by bnitz on May 29, 2006 at 01:33 PM GMT+00:00 #