Archive for the ‘unix’ Category

The Java+linux OS

Monday, November 27th, 2006

This will be an interesting trend to follow. This linux+perl distribution is made up of just linux kernel and perl binaries. Rest of the tools are all written in perl shell scripts. Miguel de Icaza, the creator of mono is looking for folks to do the same with mono.

I think its a great experiment and will help validate mono as a practical alternative to other frameworks/languages on linux. But what will be even cooler (for me atleast) is if someone can create a true Object oriented shell experience like Microsoft’s powershell/monad. And incase you didn’t know, Powershell/Monad is the new shell by Microsoft using .net framework. It will probably replace cmd sometime in the future.
That being said, it doesn’t really have to be mono. Java is a perfect candidate for it as well. There was a java project related to a java based shell which I don’t think is active anymore… may be someone can revive it.

Can it be done ?

Linux initrd (initial RAM disk) overview

Friday, August 4th, 2006

Initrd is one of those things in linux which most of us have taken for granted. Here is a very interesting writeup on how initrd really works. “The Linux® initial RAM disk (initrd) is a temporary root file system that is mounted during system boot to support the two-state boot process. The initrd contains various executables and drivers that permit the real root file system to be mounted, after which the initrd RAM disk is unmounted and its memory freed. In many embedded Linux systems, the initrd is the final root file system. This article explores the initial RAM disk for Linux 2.6, including its creation and use in the Linux kernel.

Sysadmin Day

Friday, July 28th, 2006

Pat yourselves on your back for fixing all those servers,
- doing backup,recovery and user creation.
Pat yourselves for saying no to root and yes to sudo,
- for writing ACLs and scripting voodoo…

Pat again for waking at 2am
- just to put your cellphone on charge.
..for dealing with people
- who wanted everything a day past

Pat again for reading 650 mails a day.
- for blocking SYNFIN floods on ur network
..for carrying those secure-ids
- even while you are not at work.

When you are done patting… please stop by a bar
- pick your pagers and throw away..
’cause you all need a break once in a while
- atleast on the feaking System Admin Day !!

Could the Google and Sun rumor be about Java ?

Saturday, March 18th, 2006

If you have been following writings from Daniel M Harrison you would notice how strong his convictions are on this topic. Daniel strongly believes that Google is buying Sun. And any reader who doesn’t understand how Google and Sun operate can easily be swayed to believe this. But not me.

The fact that Google or Sun haven’t publicly denied these new rumors, means that something might be cooking. But Google buying Sun doesn’t sound very interesting.

  • Sun has a large pool of talent who know how to create fault tolerant, high performance parallel processing computing infrastructure.
  • Google has a large pool of talent who have perfected the art of distributed computing using cheap hardware clusters using free tools and operating systems
  • Sun is a hardware, software and services company
  • Google makes its revenue from advertisements
  • If Google buys Sun, it would be forced to use Sun technology. Microsoft had a hard time switching Hotmail.com from FreeBSD to Microsoft based solutions.
  • The change for Google to switch to Sun based hardware and software and the time spent to do it could be quite significant.
  • A lot of goodwill for Google stems from the fact that Google is Open source friendly. Even though Sun has made attempts to open its Operating System, the perception is not the same. Google might have to face some negative publicity if they don’t take immediate damage control initiatives after a buy out.

If there is any truth to these rumors, its more likely that its about Java than anything else.

  • Google already has an agreement with Sun over cross distribution of Java and Google desktop.
  • Based on what I know, its more likely that Google might buy out Sun’s Java technology than buying the whole company itself.
  • Java is one platform which is truely write-once-run-everywhere. Nothing else comes closer to this reality.
  • Google desktop has made significant inroads into desktop world running Microsoft OS. But lacks critical foothold in non-Microsoft world. This could change if it switches to Java as the application platform for all of its client side applications
  • If Google plans to quickly build applications like GDrive and integrate writely.com with other applications running on the local operating system, it would need a more universal platform. Java, though slow, is still faster than javascript and has more access to the operating system to do such tasks.
  • With better control over how Java develops, Google could use its strong technical background to speed it up and customize it for its own applications. The way Microsoft is trying to use .NET to spread its word.
  • This may or may not be a good thing for Java. But will definitely be a awesome add on for Google.

Rsync for incremental backups

Friday, August 26th, 2005

Introduction

Archiving files to tape is still considered one of the cheapest way of making backups. However with the prices of disk storage and solid-state storage decreasing rapidly, it won’t be long before users make the switch to the faster disk storage for all thier backup needs. The problem, however, is that if you want to do anything more than mirroring data on a remote storage, there aren’t too many good freeware tools to do it. This writeup explains one of the interesting ways to do incremental backups with snapshot cabability using a popular tool called rsync.

Traditional Backup

Traditional backup applications not only support backing up and restoring of files, directories, partitions and drives, but also allow incrementally backups to reduce time taken to backup large file systems. Since its not practical to restore the complete data from tape just to apply minor changes to it, most tape backup software store the differences in a seperate file or location on tape which can be used to patch the last full backup image on the tape. This feature of storing incremental updates also allows administrators to maintain multiple versions of data without keeping as many physical copies of data. Incremental updates to backup repository is extremly valuable feature in highly dynamic environments where maintaining multiple snapshot of data taken very frequently is important.

Rsync

Rsync was one of the first tools I used, which allows one to update copies of data by sending incremental updates. This dramatically cuts down the time to update a copy of data. The problem is that though rsync allows you to make a copy of data, and allows you to incrementally update it, it was not designed with tape in mind. It specifically doesn’t allow you to keep the incremental updates in a different directory or file the way backup applications do. This limits the number of snapshots one can maintain using rsync.

The cp command

And that brings us to the last part of the puzzle which we need to know to make do incremental backups. The “cp” command on most unix operating systems allows copying of hard links (instead of the actual data). This feature allows you to maintain two physically different directories on the same partition (with different names) pointing to the same physical set of files. In linux this can be accomplised by the following command “cp -al $sourcedir $targetdir”.

Rsync + cp

To demonstrate how these two can work together to provide us snapshot capability I did some tests on my linux box. The first step was to create a small directory structure which we would be using for this exercise. “ls -ila” on the directory shows the actual “inodes” (column 1) assigned to each of these files and directories within the test directory I created.

Original Directory Structure

    List of files
    ==============================
    /tmp/test/primary
    /tmp/test/primary/file1.txt
    /tmp/test/primary/file2.txt
    /tmp/test/primary/subdir1/file3.txt
    ==============================
    
    la:/tmp/test # ls -ila primary/*
    358315 -rw-r--r--  1 root root  5 Aug 21 23:06 primary/file1.txt
    358316 -rw-r--r--  1 root root  5 Aug 21 23:07 primary/file2.txt
    primary/subdir1:
    total 4
    358313 drwxr-xr-x  2 root root  80 Aug 21 23:07 .
    358312 drwxr-xr-x  3 root root 136 Aug 21 23:07 ..
    358314 -rw-r--r--  1 root root   5 Aug 21 23:07 file3.txt
Next step is to do a traditional recursive copy from “primary” to “directory1″. You can accomplish this by either “cp” or “rsync”. In this following example I used “cp” command. Notice that when I list the inodes after the cp commands, it creates a new set of inodes for each of the files and directory in the new directory structure. This means that the traditional “cp” command did an actual recursive copy of file contents to new locations, and that there exists two identical copies of each of the objects.

After Copy using “cp -rp src target”

    la:/tmp/test # cp -rp primary directory1
    la:/tmp/test # ls -ila directory1/*
    358307 -rw-r--r--  2 root root  5 Aug 21 23:06 directory1/file1.txt
    358308 -rw-r--r--  2 root root  5 Aug 21 23:07 directory1/file2.txt
    directory1/subdir1:
    total 4
    358305 drwxr-xr-x  2 root root  80 Aug 21 23:07 .
    115666 drwxr-xr-x  3 root root 136 Aug 21 23:07 ..
    358306 -rw-r--r--  2 root root   5 Aug 21 23:07 file3.txt
Now lets see how “cp” behaves when we ask it to preserve hardlinks. In this example we are copying “directory1″ into a new directory “directory2″. Notice how the inodes in the new directory are same as the ones from “directory1″. This means that though there are two logical directories which look alike, the actual file and directories listed within each one of them are identical. Any modification done to one file within one directory (without modifying the inode) will affect the file in the other directory. This is almost same as symbolic linking, except that unlike symbolic links the file wont dissapear from “directory2″ if I delete it from “directory1″. In other words there is actually multiple owners of these inodes at this moment, which seems a little hard to digest.

“cp -la src target”

    la:/tmp/test # cp -al directory1 directory2
    la:/tmp/test # ls -ila directory2/*
    358307 -rw-r--r--  2 root root  5 Aug 21 23:06 directory2/file1.txt
    358308 -rw-r--r--  2 root root  5 Aug 21 23:07 directory2/file2.txt
    directory2/subdir1:
    total 4
    358310 drwxr-xr-x  2 root root  80 Aug 21 23:07 .
    358309 drwxr-xr-x  3 root root 136 Aug 21 23:07 ..
    358306 -rw-r--r--  2 root root   5 Aug 21 23:07 file3.txt
So we know how interesting hard links are and we know how to create multiple directories look exactly the same without creating as many copies of the actual data. A little more research on your part would reviel that if you had modified “subdir1/file3.txt” the only two inodes which would change are “subdir1″ and “subdir1/file3.txt”. I didn’t show inodes of “primary” directory in the dumps below, but what I did do is show you how the inodes look like after I rsync the changes from “primary” to “directory1″.Notice that after rsync to “directory1″ the inodes for “subdir1″ and “subdir1/file3.txt” has changed (as expected). This is because rsync usually doesn’t overwrite existing inodes. Instead it creates fresh copies of updated files and directories and deletes the old ones. Interestingly inodes of “directory2″ still shows the old inodes for the files/directories which were modified.

“directory2″ has now become a “snapshot” of “directory1″ without actually having a duplicate copy of all the data in “directory1″.

Modified file3.txt in primary copy”

    la:/tmp/test # rsync -rvgoutl primary/* directory1/
    building file list ... done
    subdir1/
    subdir1/file3.txt
    wrote 161 bytes  read 40 bytes  402.00 bytes/sec
    total size is 21  speedup is 0.10
    
    la:/tmp/test # ls -ila directory1/*
    358307 -rw-r--r--  2 root root  5 Aug 21 23:06 directory1/file1.txt
    358308 -rw-r--r--  2 root root  5 Aug 21 23:07 directory1/file2.txt
    directory1/subdir1:
    total 4
    358305 drwxr-xr-x  2 root root  80 Aug 21 23:14 .
    115666 drwxr-xr-x  3 root root 136 Aug 21 23:07 ..
    358322 -rw-r--r--  1 root root  11 Aug 21 23:14 file3.txt
    
    la:/tmp/test # ls -ila directory2/*
    358307 -rw-r--r--  2 root root  5 Aug 21 23:06 directory2/file1.txt
    358308 -rw-r--r--  2 root root  5 Aug 21 23:07 directory2/file2.txt
    directory2/subdir1:
    total 4
    358310 drwxr-xr-x  2 root root  80 Aug 21 23:07 .
    358309 drwxr-xr-x  3 root root 136 Aug 21 23:07 ..
    358306 -rw-r--r--  1 root root   5 Aug 21 23:07 file3.txt