Solaris 10 Update 5 (05/08) is out!

Solaris 10 update 5 is out! Check out the "what's new". Strangely, nothing on ZFS. Oh well...

All the same, download it at the usual place.

PAINT BOMBS!!! Weeeee~~

I really can't believe this. Spectacular!!!


This is the making of the advert:


And Sony has their write up.

Brilliant!

And a spoof:

Now for the Sony Play Doh Advertisement. WOW!!!!


Here's the making of:



Now, to find the paint advert

Sony Bubble Advertisment: COOL~~


The making of:


Time to relax. More videos please

World's Longest Slam Dunk


Randy Pausch Lecture: Really Achieving Your Childhood Dreams


Flying Penguins!

You don't believe? It's on BBC!!


1 Hour from basketball court to ice rink. Wow!


720 degree Slam Dunk!/h3>

Paintball Tank!

COOL~

Giant Waves battling lighthouses

Apparently, these footages are real... Omg...

What is the IT field all about?

Question: What is an IT career all about?

Answer: To be paid to make other people's problem your problem, so that their life will (supposedly) e better. So who fixes the plumber's pipes?

RAID-Z + JBOD or RAID-5?

I was at the SUN-NUS Opensource Day on Friday, and after the event, we all adjourned for dinner. You know, when geeks gather, we inevitably will start discussing the hacks we are deploying for one reason or the other. Or thorny problems. And hence, I brought up my "huge dataset" problem.

Now, the traditional way of doing storage carving is to do RAID-5 on the SAN, cut each RAID-5 set into smaller luns to map to the operating system. If need be, some of the luns will be RAID-1/striped together in the OS. Why? RAID-5 for redundancy, smaller luns as the RAID-5 set is too big, and striped luns to expand storage when required.

So, what's the big problem? Wee Yeh (http://prstat.blogspot.com) pointed out that lun carving is done ACROSS the RAID-5 disk set. It simply follows the way RAID-5 parity is done.

"ACROSS"!!!! Wait a moment... Doesn't this mean if a disk fails, performance is impacted across all the luns in the disk set? And if 2 disks fails, ALL the luns in the disk set are dead! So, if one lun is for applications, another is for data storage, and the third is for user directories, the entire computing stack is down. Unrecoverably dead. Geebes!!!!! <head rolls>

Of course, being a nice guy, Wee Yeh suggests using JBOD disk sets + RAID-Z using ZFS. Since ZFS will do the parity checks, there is still redundancy. If a hard disk fails, the ZFS pool continues to work. If 2 disks fail, at least the damage is contained to this ZFS pool. Added advantage is that both the SAN storage and ZFS will scream when the first hard disk dies, as opposed to only the SAN storage screaming, while the OS remains oblivious. And ZFS has parity checks during disk read/write, nicely overcoming the lack of parity read/write checks on SATA disks.

Okay, time to do some hard thinking

List of *nix commands

Now that I am doing cross platform system administration, it is getting critical to have lists of equivalent commands across the *nixes. Found 2 guides so far:

  1. Unix toolbox: http://cb.vu/unixtoolbox.xhtml
  2. Tom's Hardware Universal Command Guide: http://www.tomshardware.com/ucg/

Will be adding more as the time goes by. Smiling

Re: Data reorganisation woes

Somehow, there is no opposition to the data reorganisation plan.Yeah!!

And I found out, from a post to the LUGS mailing list, 3+ Terabytes file sharing through SAMBA and NFS(v3) has already been done. So, no more drastic hacks, for now. Wee~

Anyway, I just did a Redhat Enterprise Linux 5 kickstart file. May be posting that soon.Smiling

Disk Volume Size Limits

Yesterday, my Sun Microsystems vendor pointed out something I didn't want to think about: as my data storage climbs into multi-terabytes, our current way of storing/distributing data is no longer feasible. Damn, multi-terabyte datasets are irksome...

Here's some idea of the problem.
1) Everyone needs to see all these data, across many different computation machines.
2) Each dataset may need to be "live" for years, as research can take years to fruit. Hence, multi-stage storage strategy may not be applicable.
3) Windows XP has a 2TB volume size limit, and I do not know if CIFS/Samba can even support such big network shares.
4) Filesystem-wise, there will not be enough inodes, unless I use ZFS on Solaris.
5) Even my SAN has a problem, as each LUN can only go to 1TB. Solution? RAID-Z the LUNs.
6) And to top all these, the present dataset structure has to be reorganised, as it is just too messy to be scalable.

Let's not even talk about the network bandwidth problem...

Arrgh...... And I'm looking at scaling to 15TB in 3 years!!!

Here's to another round of persuading everyone that this is a time of changes. Aidios~

Syndicate content