Wednesday, October 10, 2007

Evil Marketing

As a techie I'm always stunned by IBM marketing... Then how many times have I read in IBM's manuals that Solaris supports only 32 LUNs or why Opterons are bad and Xeons are better (2 years ago) just because they didn't sell them back then. I don't know about you but I always value honesty. While marketing has its own rules IBM often cross the line. Too often for me.
Maybe its just that 'nobody got fired for buying from IBM' attitude in companies were techies have no say at all what company is buying and those managers are buying IBM marketing.

I don't want to say their HW is crap - honestly quite often it's good. It's just most over-hyped HW on the planet I guess and their technical documentation is hard to distinguish from marketing one. Then you should definitely check yourself all IBM's claims regarding that HW as you will quite often find it doesn't actually do what they said it will...

I totally agree with below statement:

Moral: Be VERY VERY CAREFUL when you read big blue.

Tuesday, October 09, 2007

Niagara-2 Servers

Finally Niagara-2 servers have arrived. Check T5120, T5220 and T6320. What I really like about those systems is (except T2 cpu of course) the number of disks you can put as internal disks.

The architecture document is also helpful.


I've been playing with sysbench on Solaris SPARC lately and... it surprised me how big difference compiler can make - ok I haven't been trying all the options but still...
So lets look at sysbench/cpu test - what is a difference if sysbench was compiled using gcc version 3.4.3 (-O2, -O3 basically produces similar results) vs Sun Studio 12 (-fast)

It is about 7x performance difference!

But lets look into memory test and I get mixed results - with one thread cc produced faster code, with more threads it produced slower one.

It's possible that after tweaking gcc parameters one could get similar performance to sun studio compilers (or vice verse in mem test) however people tend to compile applications with basic parameters usually. I wouldn't expect such big difference between these two compilers with larger applications... but you never know.

I'm not going into any holy-compiler wars - it's just that sometimes one can be surprised.

Friday, October 05, 2007

Encrypting ZFS

Thanks to Darren J Moffat we now have an alpha support for cryptography in ZFS.
Only bfu archives are provided for now - so if you want something more polished you've got to wait more time. Now is a good time to provide feedback, comments, etc.

Phase 1 Functionality implemented

  • Per pool wrapping key (DSKEK)
  • per dataset keytype.
    • pwrap: Randomly generated per dataset key wrapped by DSKEK
    • pool: Use DSKEK directly. Will likely NOT be supported in final release.
  • zpool keymgr load|unload|status
    • passphrase & key in file only
  • Per dataset encryption
    • NOTE: use only aes-128-cbc, aes-256-cbc
    • aes-192-cbc is broken
  • Encrypted snapshots
  • Clones "inherit" crypto properties regardless of path hierarchy clone promotion also works
  • Encryption is a create time only property
  • Encrypted datasets don't mount with 'zfs mount -a' unless key is present
  • pool history records key creation/clone.