Linux Overview for Solaris Users

It doesn't include important Solaris 10 features such as dtrace and zfs, but this (pdf) document entitled Linux Overview for Solaris Users is a good introduction to some of the similarities and differences between Solaris and Linux.

It also doesn't tell how messy Solaris's VFS is ... and nothing about Sun's marketing bullshit like ZFS.

Posted by mamamia on May 24, 2006 at 10:40 AM GMT+00:00 #

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:
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 04:33 PM GMT+00:00 #

Perhaps he's referring to the fact that ZFS still hasn't shipped yet Solaris people (I am guilty of this, too) have been touting it for the past year as an advantage over Linux. ZFS is not yet a supported shipped Solaris feature, no matter how much we wish it was.

Posted by jofa beetz on May 24, 2006 at 05:10 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 guest on May 25, 2006 at 01:31 AM GMT+00:00 #

Jofa, That is a fair point. ZFS is still only available via Solaris Express and other unsupported opensolaris releases. I wish Sun could figure out a support model for products which fall between "more stable than Microsoft Windows" and "stable enough to run multibillion dollar businesses for decades." Someone will.

Posted by bnitz on May 25, 2006 at 02:34 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 03:06 AM GMT+00:00 #

VFS just wasn't designed for them probably. or they don't understand it well. the point is that VFS implements model and does it very well. in contrary, Solaris has no VFS at all. silly methods switcher and dnlc can't be considered a good model -- just an ugly hack. I also remember how VFS did help to filter reiser4 crap from getting to the kernel. for case of Solaris, nothing would prevent a stupid developer to do absolutely wrong things ...

Posted by mamamia on May 25, 2006 at 04:15 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 04:30 AM GMT+00:00 #

nice, how long it took to fix rename race? I want checksums, but definitely not at this cost. and that would be really unexpected to see users complaining about internals like size of block pointers. given how much marketing bullshit Sun puts everywhere about Solaris/ZFS, I tend to think time when Sun was for engineers has gone and new niche is "all those idiots who prefer 128bit fs over really good and balanced design".

Posted by mamamia on May 26, 2006 at 12:26 PM 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 26, 2006 at 05:25 PM GMT+00:00 #

there is no way to bechmark ZFS against different filesystem because ZFS is Solaris-only and UFS2 isn't that modern. if you're going to use it for your .html/.doc, re-calculating all blocks is OK. but if you need to modify few thousand files every second, write >1GB/s, such a re-calculation is going to be too expensive. if you're that interested in adding another hard drive, you should have known this feature has been existing for a decade and called LVM.

Posted by guest on May 27, 2006 at 02:09 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 04:48 AM GMT+00:00 #

lol. writing >1GB/s is unusual for Sun/Solaris? when you write at those rates, every written/checksummed block is important for performance. and ZFS does much more than needed. at cost of performance, of course.

LVM2 does all things online, including rw snapshots. I can write a few-line shell script that will be named zpool, will add a drive to given fs and will resize fs properly. surprize?

PS. i'm shocked how effective Sun's marketing department, especially for own staff.

Posted by guest on May 27, 2006 at 05:20 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 06:33 AM GMT+00:00 #

Post a Comment:
Comments are closed for this entry.



« July 2016