Solaris on Mac Book

Over the weekend, I had an access to a New Mac Book (One of my cousin's) for a
very short period of time. It comes with 32 bit x86 class of processor. It
had Mac OSX and Windows XP installed using the Boot Camp software.

The first thing I wanted to try is to boot the Mac Book using Belenix.
Unfortunately, I did not have a copy of Belenix image to try it out. However, I
had a Solaris Installation DVD (One of the latest build) handy and decided to
test it.

After powering ON the Mac Book, while pressing the alt key, I inserted the
Installation DVD. The Mac Book waited for a while and threw a screen which had
three boot options :





Macintosh (HD), Windows (HD), Windows (DVD)

Interestingly, Boot Camp considers any non-OSX as Windows. This brings a RFE
to the Boot Camp project team to identify other Operating Systems like
Solaris, BSD, Linux and Windows while booting.

I selected the Installation DVD to boot :





The primary boot loader of Solaris Grub immediately got the control :





Then, I selected the default option to boot. There was a progress, of files
being read from the Installation DVD :





Bingo !!!

I got the Solaris Copyright message from the Kernel and the installation
options from the Solaris installer without any problem :





I then selected the Interactive method of Installation :





It then started the graphics (Generic VESA mode) too without any issues :





I then issued couple of commands to get the hardware details :









I was too tempted to blow away the Windows Installation with Solaris, but then
It was not my Mac Book. I had to stop playing with Solaris on the Mac Book at
this point.

The only problem I had, mouse pad did not work under Solaris. I used one of my
USB mouse as a workaround.

I was so happy to see Solaris booting on this excellent piece of hardware,
Mac Book without having to modify anything. Solaris had definitely come a
long way to reach where it is today. It is because of the hard work, we many of
the engineers at Sun have put till date.

I am sure that Solaris will improve in the near future too, so that it can run
on the Mac Book for production purposes.

This experiment infact is pushing me to spend around 2 grand to get a Mac Book
as an upgrade from my 3 Year old laptop.

I made up my mind that, I would consider a Mac Book iff it is available with a
64 bit x86 class of processor, so that I can run 64 bit Solaris. I hope the
Mac Book Pro will be using 64 bit processors soon. This atleast stops me
spending a bulk of buck as of now :-)

Posted at 07:05PM Jul 31, 2006 by prabahar in General  |  Comments[0]

ZFS on Solaris 10

I, along with couple of my colleagues were working on delivering ZFS for Solaris 10 since last Christmas. We completed the work recently and we now have builds of Solaris 10 with ZFS for Sun's internal use.

For our customers, ZFS for Solaris 10 will be available soon along with Solaris 10 U2.

We would really appreciate if you use ZFS and provide us your feedback.

Posted at 03:20PM May 14, 2006 by prabahar in General  |  Comments[0]

ZFS : The Last Word in File Systems...

Today, Sun released a revolutionary storage technology called ZFS along with Solaris Express.
A small quick Demo gives you a glance about ZFS.
If you are curious about the internal implementation, have a look at The ZFS source

Posted at 09:55AM Nov 16, 2005 by prabahar in General  |  Comments[0]

Solaris UFS lockfs protocol

On  the event of today's full release of OpenSolaris  (Open Source version of Solaris -- The Best Operating System in the Planet), I would like to explain a small piece of Solaris UFS and an interesting BUG I fixed in the piece recently.

Solaris UFS lockfs Protocol :

Purpose :
* Provides a facility to quiescen a file system
* Provides a facility for file system locking
* Provides a facility for forced unmount

UFS VNODE  Operations :
Various VNODE operations for implementing UFS is defined by ufs_vnodeops. On a running system to find out the functions of UFS VNODE operatios, as root type : "echo 'ufs_vnodeops::print vnodeops_t' | mdb -k"

Interface for user land :

IOCTL _FIOLFS on a UFS

Interface for ufs_vnodeops :

ufs_lockfs_begin{_getpage}()
ufs_lockfs_end()
ufs_quiesce()

The Protocol :

Various lock state of a UFS :

* WRITE LOCK

Suspends writes that would modify the file system. Access times are not kept while a file system is write locked.

* NAME LOCK

Suspends accesses that could change or remove existing directories entries.

* DELETE LOCK

Suspends access that could remove directory entries.

* HARD LOCK

Returns an error on every access to the locked file system, and cannot be unlocked. Hard Locked file systems can be unmounted. Hard lock is for supporting forcible unmount.

* ERROR LOCK

Blocks all local access to the file system and returns EWOULDBLOCK on all remote access. File systems are error locked by UFS on detection of internal inconsistency. They may only be unlocked after successful repair by fsck, which is usually done automatically. Error locked file systems can be unmounted. Once the file system becomes clean, it may be upgraded to a hard lock.

* SOFT LOCK

Quiescens a file system.

* UNLOCK

Awakens suspended accesses, Releases existing locks, Flushes the file system.

ufs_vnodeops functions  that conflict with the above file system lock types will get either suspended, or get a EAGAIN error, or get an EIO error if the file system is hard locked, or will block if the file system is error locked.

A per UFS counter  will get incremented by 1 when a ufs_vnodeops is entered; it will be decremented by 1 when a ufs_vnodeops is exited.

A file system is in a quiescent state if  the counter is zero.

When a ufs_vnodeops is under execution on a UFS, there can be a call to another  function of  ufs_vnodeops on the same UFS or a different UFS. This is called as recursive  ufs_vnodeops. The per UFS counter is not incremented or decremented during the recursive ufs_vnodeops.

There are exceptions that the following ufs_vnodeops do not obey the locking protocol :
ufs_open, ufs_close, ufs_inactive, ufs_rwlock, ufs_rwunlock, ufs_putpage, ufs_addmap, ufs_delmap, ufs_poll

Implementation of The Protocol :

The structure ulockfs  used to implement UFS lockfs protocol is embeded into and part of ufsvfs_t . It is created while mounting a UFS and stored in vfs_data of vfs_t .

The member ul_vnops_cnt of structure ulockfs acts as a per UFS counter. It  will be incremented (ufs_lockfs_begin{_getpage}())  by 1 when a ufs_vnodeops is entered; it will be decremented (ufs_lockfs_end()) by 1 when a ufs_vnodeops is exited.

A file system is considered to be in a quiescent state (ufs_quiesce()) if ufs_vnops_cnt is zero.

The function ufs_check_lockfs()  checks whether any of ufs_vnodeops function conflicts with the file system lock types. If it conflicts then it will either suspend or return EAGAIN or  EIO or  EWOULDBLOCK based on current file system lock state.

To detect recursive ufs_vnodeops, ulockfs_info_t  is attached to every thread who calls one of the function from ufs_vnodeops.

Real World Advantages :
* HA service fail over with the help of forced umount
* Stop the file system activity for taking backups
* Provides a reliable method for synchronous flush of all the file system data to disk.
 

BUG 4648917 :
I  fixed a long lasting BUG 4648917  in Solaris 10  to correct the broken UFS lockfs protocol. The broken piece - UFS lockfs implementation fails to detect recursive ufs_vnodeops on different file systems. As a result, sometimes the system panics if one of the file system is forcefully unmounted.

A system suffered due to BUG 4648917 will have  stack trace (SPARC version) in the crash file like :

ufs_getpage                ---> (A)
segvn_fault
as_fault
pagefault
trap
ktl0
hat_memload
uiomove
wrip
ufs_write                       ---> (B)
vn_rdwr
core_write
core_seg
do_core
psig
post_syscall
syscall_trap

The system panicked when a process trying to dump core due to an unexpected signal delivery. At (A) and (B) a thread from the process is doing recursive ufs_vnodeops on different file systems. The test case we came up with, was just a while (1) loop program with big data segment (Several Mega Byte of a static array).

To reproduce the problem, on a system have two UFS (root, and another file system). Have the test program stored on the other file system. Start the test program from root. Send SIGFPE to the test program and forcefully unmount the other file system in parallel.

When the program receives SIGFPE the default signal handler initiates the core dump. While creating the core file (B) (Kernel writes the entire address space of the process)  kernel detects that some part of the process' data segment is not available in the process' address space. Hence it needs to be brought into the process' address space from the file system (A).

In the meantime the other file system where the executable of the process is stored was forcefully unmounted. Due to the BUG 4648917 the forcible unmount was allowed during an on going ufs_vnodeops on the other file system.

Since, the file system was unmounted during an on going ufs_vnodeops the system ended up in a panic state due to an unexpected data fault.

The root cause for the problem was -- The earlier UFS lockfs protocol implementation used  the flag T_DONTBLOCK  in t_flag,  of kthread_t to indicate that a thread has entered one of function of ufs_vnodeops. Single flag  obviously fails to detect the recursive ufs_vnodeops on different file systems.

I fixed this BUG by attaching  ulockfs_info_t  to every thread who calls one of the function from ufs_vnodeops on a UFS for the first time. Recursive ufs_vnodeops is detected by checking the thread for ulockfs_info_t.

---

Technorati Tag : OpenSolaris
Technorati Tag : Solaris
Technorati Tag : mdb

Posted at 04:20PM Jun 14, 2005 by prabahar in General  |  Comments[1]

Open Solaris

The big day for Sun. Yes today we announced OpenSolaris

Visit

http://www.opensolaris.org

Posted at 04:07PM Jun 14, 2005 by prabahar in General  |  Comments[0]

Introduction

Hey I am Prabahar Jeyaram. I am here to join the party.

I work with Sun Microsystems' Solaris Sustaining and Engineering Group since December 1999.

One of Sun Microsystems' greatest contribution to the world is SOLARIS -- The best operating system in the planet Earth. It helps to run mission critical applications in industries, businesses, enterprises and organizations all over the globe.

Even though it is the most reliable robust piece of software, an occasional broken rivet or a loose bolt can bring a system to grinding halt. This is where I come into the picture.

We are a group of more than a hundred dedicated experts, spread across various time zones, always on alert like the doctors in an emergency care unit to keep Solaris alive and kicking. I not only find and fix the broken rivet to customer's satisfaction, but also ensure that Solaris improves to the perfection.

Apart from My family and Work, I like electronics and playing with electronic gadgets.

Posted at 11:06AM May 25, 2005 by prabahar in General  |  Comments[1]