Coyote's Blog

Problem At a large company, the DBA teams migrating Oracle databases from Solaris/Sparc to RHEL5/x86 had a major pain point: - dumping/exporting the database was easy, converting its endianness was simple and re-importing it on the Linux side was easy too. -HOWEVER- transferring the dump from one system to another was 1) slow and 2) unpredictable (large VLAN's make for increased latency and slower transfers). If your DB was pretty small, you would just wait for a few hours but with a database of a few Tb, it just wasn't practical. Solution: Use a shared and compressed ZFS pool on a SAN box and enjoy transfer-less database dumps. Solaris/Sparc and Solaris/x64 speak ZFS natively but Linux doesn't, unless you use zfs-fuse (http://zfs-fuse.net). ZFS-fuse installs without reboot and makes your zpool available instantly. Here's the howto: 1) Install zfs-fuse from http://vscojot.free.fr/dist/zfs-fuse on your Linux box (here, an HP DL580G7): vcojot@rhel5x64$

A long time ago, when 64mb were a huge amount of RAM, there used to be that GUI environment named 'OpenWindows', evolved from SunView and from some research at Xerox.  In its time (early 90's), it was liked by many (SUN people, mostly, I guess) and despised by others because it was deemed 'too heavy' when compared to other window managers (fvwm, twm, etc...).Read more about it here: http://en.wikipedia.org/wiki/Openwindows. Why is all this relevant today? In late 2011, some small parts of the full OpenWindows DeskSet were ported to Linux (yes, ported). This included the libdeskset library, and one of its most popular apps: The File Manager. It's still relevant today because, in these 2012 times of metacity and RHEL6 desktops, the OWacomp desktop still feels 'snappier' than many other 'bundled' desktop environments. I agree that GNOME or KDE have come a long way but whatever the 'theme', they just don't feel as 'snappy'

VxFS 6.0 and compression (a real must have). Here's a little personal info: I like good movies and good anime (for the kids). I like them even better when stored as DVD5 or DVD9 iso images for playing them with VLC (VideoLan Client) on the wide-screen TV. But as my list of DVD's grew, my VxFS 3Tb filesystem started to become full (about 400 DVDs). With VxFS version 9 compression feature, I gained some time and was able to reclaim some space.. First of all: 1) Upgrade to SF6.0 2) Upgrade your DG (vxdg upgrade <dg>) 3) Upgrade your filesystem (vxupgrade -n 9 <fs>) Which gives: [root@thorbardin ~]# vxdg  upgrade local00dg [root@thorbardin ~]# vxupgrade -n 9 /export/home/raistlin/.private/movies0 UX:vxfs vxupgrade: ERROR: V-3-25236: /dev/vx/rdsk/local00dg/movies0_lv: already at disk layout version 9. [root@thorbardin ~]# find /export/home/raistlin/.private/movies0/DVD -name \*.iso|wc -l 512 So we have 512 DVD images on this FS. Let&

For those of you who don't want to watch Symantec's video, here's a quick & cheap howto of a VxFS de-dupe test using SFHA 6.0 under RHEL5.8: * First, here's our setup: [root@vcs11 ~]# df Filesystem           1K-blocks      Used Available Use% Mounted on /dev/mapper/rootdg-lv_root                       15109112   9258676   5070560  65% / /dev/sda1               101086     20027     75840  21% /boot tmpfs                  1029372         0   1029372   0% /dev/shm tmpfs                        4         0         4   0% /dev/vx /dev/vx/dsk/vcsdg/lv_vcs                         131072      4473    118813   4% /shared/vcs   * Let's check the initial state of this setup: [root@vcs11 ~]# /opt/VRTS/bin/fsadm -S shared /shared/vcs  Mountpoint    Size(KB)    Available(KB)   Used(KB)   Logical_Size(KB) Space_Saved(KB) /shared/vcs      131072        118813       4473             4473             0 * Enable de-dupe for our test filesystem: [root@vcs11 ~]# /opt/VRTS