The fsck of IBM Storage Scale

What is fsck
Wikipedia says : The system utility fsck (file system consistency check) is a tool for checking the consistency of a file system in Unix and Unix-like operating systems, such as Linux, macOS, and FreeBSD.

A file system is a method of storing, organizing, and managing the data in the available storage medium.
File system consistency refers to the correctness and validity of a file system.  Faults in a file system are usually caused by power failures, hardware failures, or improper shutdown of the system.

All file systems have their own ways of storing the data structures stored on the storage medium.  So fsck works with the data structures on disk.  Thus fsck is always available for a specific file system.  In other words, every file system must have its own fsck program.

Before running fsck to check the health of a file system, the file system must be unmounted.


Why is fsck needed

Considering the reliability of the hardware available these days and the robustness of the software, it is rare for a file system to have data corruptions. However, if in case data corruption happends in a file system, it needs to be detected and repaired.

In case of a power failure, the server may not shutdown correctly.  In this case, the data in the memory may not get written to the disk.  This creates inconsistency.  Such inconsistencies, if not corrected, may create further trouble later.

In rare cases, disks have bad sectors. The disks with bad sectors need to be replaced. Then fsck needs to be run to ensure data integrity.

If the applications are reporting input/output errors when accessing or storing data, the file system may have inconsistencies and running fsck is needed in such cases.



What is IBM Storage Scale
IBM's clustered file system that provides parallel data access from multiple nodes is branded as Storage Scale.

To know more about Storage Scale, please visit https://www.ibm.com/docs/en/storage-scale/5.1.8?topic=overview-storage-scale

Here is a brief overview of IBM Storage Scale.
Storage Scale is a file system. But not an ordinary file system running locally on a single computer. Storage Scale runs on multiple computers. These computers together make a cluster. They are known as the nodes of the cluster.  Some of the nodes are arranged access to a storage that is present in the network. The storage is available to the nodes in the form of Network Shared Disks (NSDs). The available NSDs are used to create file system.  Customers use the file system to store and access data, via NFS, CIFS, or object protocols.

Storage Scale provides concurrent high-speed file access. Applications that access the data may be running on multiple systems and accessing the data in parallel.

A storage Scale cluster may consist of 1 to 56 nodes.  The nodes could be assigned the roles of quorum nodes and data nodes.  Rather than entering into the details of Storage Scale, let's focus on our agenda - fsck.



The fsck of IBM Storage Scale
As mentioned earlier, the fsck tool is always specific to a particular file system. For Storage Scale, IBM's engineers have written their own fsck program which is specific to Storage Scale.  It is named mmfsck.  All commands of Storage Scale begin with mm.  If you wonder why, mm stands for multi media.  This file system was developed 25 years ago.  In those days, having a big storage was a super luxury. Multi media was an emerging technology. And the storage required for multi media was supposed to be in huge quantity. As per the trend, all commands of the new file system were named with mm.

When IBM engineers developed this new file system, they developed the mmfsck tool as well. The file system has to be unmouted before running mmfsck on it. Are you thinking "this is a limitation"?  Well, although unmouting the file system for running fsck is a necessity, but some of us do think differently.  Why do I must have a downtime for running mmfsck? Why can't it be done while the file system is online and in use?  We took this thought forward and developed another variant of fsck which does not require the file system to be unmounted. It works while the file system is mounted and in use. We named it mmfsckx.  The x stands for eXtended.

So for Storage Scale now we have two variants of fsck.  mmfsck which requires the file system to be unmounted and mmfsckx which works while the file system is mounted and in use.  Typically we refer mmfsck as offline fsck and mmfsckx as online fsck.

Although the user may not be aware of this, the fsck is a separate program from the file system kernel code. Their intentions are also different. The fsck analyzes the file system’s metadata for the purpose of performing repairs. The kernel code manages the file system’s operations during normal usage.

Is Storage Scale the only file system that has online fsck?  Obviously not.  For example, see XFS Online Fsck Design and BeeGFS File System Check

What next?
Okay, you have a niche file system that allows to run fsck without unmounting, that means without a downtime involved. So can you improve what you already have?  Can you go beyond?  When this thought came to my mind, here are the subsequent thoughts that followed.

1. fsck for filesets
Say we have a huge file system that is being used in a multi-tenant cloud environment.  In some cases, we have a separate fileset for every customer, or "fileset-based multi-tenancy".  Filesets is a method of dividing the file system to have separate access and administrative operations.

Running online fsck on a huge file system would take a long time. It could take be a few days, depending on the amount of data present in the file system. And if a problem is reported by a particular customer, then we would know the fileset in question.  A fileset is a part of the file system that could be used separately.  So why not run online fsck on a single fileset or multiple filesets, rather than on the entire file system?  Of course, running online fsck on a fileset may not detect all issues. But it is a good start. If we could detect and repair all issues in the fileset, then we would avoid to run online fsck on the entire file system.  That would be a big bonus. If we could defect some of the issues in a fileset, I'd say that is still a battle half won. So running online fsck on filesets is a useful functionality we'd want to have.
To know more about filesets, please visit https://www.ibm.com/docs/en/storage-scale/5.1.8?topic=scale-filesets

2. Self healing filesystems
If some part of a disk goes bad, the data corruption may not be noticed immediately.  Detecting such data corruption much later may lead to unwanted consequences. So what if these situations could be avoided proactively?  Is there a way?  What if we have a program that identifies that the system is now idle and runs online fsck during the idle interval?  So the data corruptions are detected and repaired before they are noticed by the users of the data.  A self healing file system is the true masterpiece we'd want to have.

3. Self healing filesets
As mentioned earlier, running online fsck on a huge file system would take a long time, depending how much is the data stored in the file system.  So if we could have the online fsck to run on a single fileset or multiple filesets, then we could use that feature during the idle intervals of the Storage Scale cluster.  So by combining the two features together, we would have self healing filesets.  Is there a cloud that has already implemented this?  If you know, you tell me  :-)

4. Performance
When we think about performance, there are two aspects to consider :
(a) For a given file system, how much time is taken for running offline fsck vs online fsck
(b) What can be done to improve the performance of running online fsck
Let's consider these one at a time.

(a) For a given file system, how much time is taken for running offline fsck vs online fsck
When we run offline fsck, the file system is unmounted and so there is no IO workload.  So load on the worker nodes is low.  While running online fsck, the file system is mounted and IO workload is in progress.  So load on the worker nodes may be high, depending on the IO workload.  Considering these situations, time required for running offline fsck is usually much less than the time required running online fsck.  In theory, we all would agree to this.  The results obtained during functional testing indicate that the time difference is not much when the amount of data in the file system is of small quantity.  The more the amount of data in the file system, the more is the time difference.  When the file system contained enormous amount of data, say in quantities of petabytes, then the time difference is huge.  In one particular case the online fsck took 10 times more time than offline fsck.

(b) What could be done to improve the performance of running online fsck
By default, online fsck uses all available nodes of the cluster to do the work.  The total work is divided in portions. Each node does some part of the work.  The file system manager node manages the distribution of work.
Not all nodes of the cluster would have the same amount of memory and processing power.  Also IO workload may not be the same on all nodes of the cluster.  So if there are say 15 worker nodes, making 15 portions of the entire work and allocating one portion to each node may not be the efficient strategy.

Depending on the available memory, available processing power, and load on each node, certain amount of work could be allocated for each node which would be appropriate to distribute the work evenly amongst all available nodes.  Moreover, if the execution is taking huge amount of time, then the amount IO workload on the nodes may vary at later times.  So the original calculation of evenly distributing the work may not remain to be the most efficient at a later time.  In such cases, a recalculation to evenly distribute the remaining work between the nodes would be beneficial.

Another simpler strategy is also possible. Not all nodes would finish their portion of the work at the same time.  Some may finish earlier than others, depending on the IO workload. The nodes which complete their portion of the work may be allocated a smaller portion of the remaining work. This redistribution of work would help to complete the entire work in lesser time.

There could be more ways to improve performance of online fsck that I could not list here.  Some food for thought for the reader.



References
1. https://en.wikipedia.org/wiki/Fsck
2. https://lwn.net/Articles/248180/
3. https://www.adminschoice.com/repairing-unix-file-system-fsck
4. https://linux.die.net/man/8/fsck
5. https://www.ibm.com/docs/en/aix/7.3?topic=f-fsck-command
6. https://www.ibm.com/docs/en/storage-scale/5.1.9?topic=reference-mmfsckx-command

A rescue near The Hidden Castle

The Hidden Castle is a castle-themed resort in Medak district near Hyderabad, India.  To reach there from the city is approx. 2 hours drive.  We were still astonished by the grand theme of this place when we checked in to the attic room that we had booked during our family vacation.

While gazing out of the window of our room, we heard cries of a dog coming from some distance.  From the farms that were beyond the resort.  The dog was nowhere to be seen. But the cry for help was repeating.  During the afternoon and the evening I made attempts to cross the boundary of the resort, but the fence was an obstacle I could not overcome.  All night the dog was crying for help.

The next morning, a short hike was arranged for all guests by the resort staff.  While going for the hike, I found the way to walk out of the resort towards the area where the dog was crying.

After the trek, I and my daughter stepped out to find where the dog was and what was the matter with it.  A search through some thorny bushes towards the source of the sound lead me to the dog who was tied to the fence with a metal chain.  I untied the chain from the fence.  But the dog was too tired to even stand up.  The two biscuits I gave were not sufficient to restore the energy.

 

Khushi jumped over the fence and untied the chain from the dog's neck.  There was nobody to be seen in the rice farms.  Why to tie the dog in the farm and leave him starving for days.

The dog was completely exhausted and could not stand up.  I ran to the kitchen of the resort and got some slices of bread.

After eating the bread pieces the doggy made attempts to stand up.

After some time we had to leave the doggy and come back in the resort.  Our room checkout time was already over.  When we started walking, the doggy got up and we saw he had thee legs.  One leg was missing.  He knew the path where he wanted to go.  Khushi and I jumped over the fence.  Observing that we left the farm and went on the other side, the doggy kept howling and asking us to join him instead.

Our time with the doggy was limited and over.  And the same is for all of us.

यथा काष्ठं च काष्ठं च समेयातां महोदधौ ।
समेत्य च व्यपेयातां तद्वद् भूतसमागम: ॥

If this world is considered to be a big ocean, then we all are like logs of wood floating around.  We come together and then are separated.  None of us are permanent companions.  All we have is to spend our time together while we are together.  The dog is also a living being.  Why tie him to starve?  Wouldn't we want to help our fellow beings to be free?  Isn't that the purpose we are given.  In medieval times folks used to go to Kashi to attain freedom from this mortal world.  In this modern age, someday I want to visit Muktinath, known to be a Mukti Kshetra, which literally means the 'liberation arena'.  What worked in the Golden Age (Satya Yug) would not work in the modern times (Kali Yug).  Rather than the rituals and the mantras, Karma is the formula for Kali Yug, the modern times.

How to uninstall IBM Spectrum Scale

There are situations when IBM Spectrum Scale needs to be uninstalled.  Here a step by step guide for doing this.

What is IBM Spectrum Scale
IBM's clustered file system that provides parallel data access from multiple nodes was branded as Spectrum Scale.  It is now re-branded as IBM Storage Scale.

To know more about IBM Spectrum Scale, please visit https://www.ibm.com/docs/en/storage-scale/5.1.8?topic=overview-storage-scale

IBM Spectrum Scale is a file system. But not an ordinary file system running locally on a single computer. Spectrum Scale runs on multiple computers. These computers together make a cluster. They are known as the nodes of the cluster.  Some of the nodes are arranged access to a storage that is present in the network. The storage is available to the nodes in the form of Network Shared Disks (NSDs). The available NSDs are used to create file system.  Customers use the file system to store and access data, via NFS, CIFS, or object protocols.

IBM Spectrum Scale provides concurrent high-speed file access. Applications that access the data may be running on multiple systems and accessing the data in parallel.

A Spectrum Scale cluster may consist of 1 to 56 nodes.  The nodes could be assigned the roles of quorum nodes and data nodes.

Before we begin
A spectrum scale cluster consists of one or more nodes.  At every node of the cluster, the spectrum scale packages are installed.  Apart from the packages, some files and directories are present which are required for the functioning of the node.  This procedure is of uninstalling Spectrum Scale from a single node.

Pre-checks
Before uninstalling spectrum scale from a node, please check :
(a) Is the node part of a spectrum scale cluster?  Run command mmlscluster to check this.
(b) Does the node have NSDs?  Are the NSDs local to the node or are they shared NSDs?  Are any of the NSDs being used?  Run command mmlsnsd to check these.
(c) Are any spectrum scale file systems mounted at this node?  Run command mmlsmount to check this.

Uninstallation Procedure

1. If the node has any file systems mounted, then all file systems must be unmounted from this node.  Unmount all file systems from the node by running command mmumount all
Verify that the node does not have any spectrum scale file system mounted by running command mmlsmount all

2. If the node has shared NSDs, then all shared NSDs should be removed.  In this case, please think for a while "why are we really uninstalling spectrum scale from this node?  Is this really necessary?"  If answer is affirmative, then please proceed to remove all the shared NSDs.  For doing so, the shared NSDs must be in unused state.  Please check if any of the shared NSDs are being used in any spectrum scale file system(s).  If yes, then remove the NSDs from the file system(s) using command mmdeldisk
Verify that the NSDs in question are in unused state by running command mmlsnsd
Delete the NSDs by running command mmdelnsd
Verify that the NSDs in question are deleted by running command mmlsnsd

3. If the node has local NSDs, then all local NSDs should be removed.  Please check if any of the local NSDs are being used in any spectrum scale file system(s).  If yes, then remove the NSDs from the file system(s) using command mmdeldisk
Verify that the NSDs in question are in unused state by running command mmlsnsd
Delete the NSDs by running command mmdelnsd
Verify that the NSDs in question are deleted by running command mmlsnsd

4. If the node is part of a spectrum scale cluster, then it should be removed from the cluster.  To do so, login to any other node in the cluster, and run command mmdelnode
Verify that the node is not part of the cluster by running command mmlscluster

5. If the spectrum scale software is running at the node, stop it by running command mmshutdown

6. Remove all spectrum scale packages that are currently installed.
Some of the spectrum scale packages have dependencies, and can not be removed individually.  So all spectrum scale packages should be removed together using a single command.

On a node running Red Hat Enterprise Linux, you could run `rpm -qa | grep gpfs` to get a list of spectrum scale packages that are currently installed.  For example :

# rpm -qa | grep gpfs
gpfs.base-5.1.8-2.230821.114705.ppc64le
gpfs.adv-5.1.8-2.230821.114705.ppc64le
gpfs.license.dev-5.1.8-2.230821.114705.ppc64le
gpfs.gpl-5.1.8-2.230821.114705.noarch
gpfs.crypto-5.1.8-2.230821.114705.ppc64le
gpfs.compression-5.1.8-2.230821.114705.ppc64le
gpfs.msg.en_US-5.1.8-2.230821.114705.noarch
gpfs.gskit-8.0.55-19.1.ppc64le
gpfs.base-debuginfo-5.1.8-2.230821.114705.ppc64le
gpfs.docs-5.1.8-2.230821.114705.noarch
#

Remove the packages by running command `rpm -e package_name`.  For example :

# rpm -e gpfs.base-5.1.8-2.230821.114705.ppc64le gpfs.adv-5.1.8-2.230821.114705.ppc64le gpfs.license.dev-5.1.8-2.230821.114705.ppc64le gpf
s.gpl-5.1.8-2.230821.114705.noarch gpfs.crypto-5.1.8-2.230821.114705.ppc64le gpfs.compression-5.1.8-2.230821.114705.ppc64le gpfs.msg.en_US-5.1.8-2.230821.114705.noarch gpfs.gskit-8.0.55-19.1.ppc64le gpfs.base-debuginfo-5.1.8-2.230821.114705.ppc64le gpfs.docs-5.1.8-2.230821.114705.noarch

Verify that the packages are removed by running command `rpm -qa | grep gpfs`


On a node running Ubuntu, you could run `apt list | grep gpfs` to get a list of spectrum scale packages that are currently installed.  For example :

# apt list | grep gpfs
gpfs.adv/now 5.1.8-2.230821.114705 ppc64el [installed,local]
gpfs.base-debuginfo/now 5.1.8-2.230821.114705 ppc64el [installed,local]
gpfs.base/now 5.1.8-2.230821.114705 ppc64el [installed,local]
gpfs.compression/now 5.1.8-2.230821.114705 ppc64el [installed,local]
gpfs.crypto/now 5.1.8-2.230821.114705 ppc64el [installed,local]
gpfs.docs/now 5.1.8-2.230821.114705 all [installed,local]
gpfs.gpl/now 5.1.8-2.230821.114705 all [installed,local]
gpfs.gskit/now 8.0.55-19.1 ppc64el [installed,local]
gpfs.license.dev/now 5.1.8-2.230821.114705 ppc64el [installed,local]
gpfs.msg.en-us/now 5.1.8-2.230821.114705 all [installed,local]
#

Remove the packages by running command `apt remove package_name`
For example :

# apt remove gpfs.adv gpfs.base-debuginfo gpfs.base gpfs.compression gpfs.crypto gpfs.docs gpfs.gpl gpfs.gskit gpfs.license.dev gpfs.msg.en-us

Verify that the packages are removed by running command `apt list | grep gpfs`.  For example :

# apt list | grep gpfs
gpfs.adv/now 5.1.8-2.230821.114705 ppc64el [residual-config]
gpfs.base/now 5.1.8-2.230821.114705 ppc64el [residual-config]
gpfs.compression/now 5.1.8-2.230821.114705 ppc64el [residual-config]
gpfs.crypto/now 5.1.8-2.230821.114705 ppc64el [residual-config]
gpfs.docs/now 5.1.8-2.230821.114705 all [residual-config]
gpfs.gpl/now 5.1.8-2.230821.114705 all [residual-config]
gpfs.gskit/now 8.0.55-19.1 ppc64el [residual-config]
gpfs.license.dev/now 5.1.8-2.230821.114705 ppc64el [residual-config]
gpfs.msg.en-us/now 5.1.8-2.230821.114705 all [residual-config]
#

Notice that the packages are not installed, but the configuration data still remains.  To completely remove spectrum scale from the node, the configuration data needs to be removed as well.  If this is not done, and later if this node needs to be added to another spectrum scale cluster, then that would be a problem, because of the existing old configuration.

7. Remove the /var/mmfs directory
# cd /var
# rm -rf mmfs/

8. Remove the /usr/lpp/mmfs directory
# cd /usr/lpp
# rm -rf mmfs/

9. Remove all files in the /var/adm/ras directory
# cd /var/adm/ras
# rm -rf *

10. Remove the /tmp/mmfs directory
# cd /tmp/
# rm -rf mmfs/

11. Reboot the node


This is how spectrum scale could be uninstalled from a node.  If you want to uninstall spectrum scale from a cluster, then uninstall spectrum scale from all nodes of the cluster.


Summary
Uninstalling spectrum scale from a node is not simply removing the packages that are installed.  There are some steps involved before removing the packages and after removing the packages.  If the node is part of a cluster, then appropriate care should be taken so that the NSDs in use and the other nodes in the cluster are not affected.

रुद्राक्ष

 ह्यावर्षी काठमांडू मधल्या पशुपतीनाथ मंदिराला भेट दिली तेव्हा तिथल्या दुकानांमध्ये रुद्राक्षाची फळं विकायला पाहिली.  छोटी फळं नेपाळी दहा रुपयाला एक फळ.  मोठी फळं नेपाळी वीस रुपयाला एक.  थोडी घेतली.  भारतीय दहा रुपयाला नेपाळी सोळा रुपये मिळतात.  फळातून रुद्राक्ष बाहेर काढणार त्यामुळे तो खत्रिशीर अस्सल.  रुद्राक्ष ह्या विषयावर धार्मिक रंग दिलेली अर्धसत्य माहिती असंख्य प्रमाणात उपलब्ध आहे.  पण रुद्राक्ष कसा बनतो, त्याचं झाड कोणतं ह्या प्रश्नांची उत्तरे शोधली तर मराठीत काही सापडले नाही.  ती उत्तरे शोधताना विचार सुचला कि हे मराठीत लिहावं.  त्यामुळे हा लेखनप्रपंच.

फळे

वृक्ष
Botanical name = Elaeocarpus sphaericus
शास्त्रीय नाव =  इलेओकारपस स्फेरिकस  
सदाहरित, दुष्काळात तग धरून राहणारे, औषधी गुणधर्म असलेले हे वृक्ष ४५ ते १०० फूट वाढतात.
Elaeocarpus ह्या वंशाच्या ३५० प्रजाती ज्ञात आहेत.  त्यापैकी ३५ भारतात आढळतात.
ह्या वृक्षाच्या पानं, फळं, आणि बियांत औषधी गुणधर्म असतात.

हे वृक्ष कुठे आढळतात
इंडोनेशिया, फिलिपिन्स, थायलंड, म्यानमार, नेपाळ, भूतान, बांगलादेश, भारत ह्या देशात हे वृक्ष वाढतात.
रुद्राक्षांच्या मागणीमुळे भारतातला ह्या वृक्षांचा नैसर्गिक प्रदेश आणि संख्या कमी झाली आहे.  भारतात हा वृक्ष दुर्मिळ झाला आहे.  सध्या उत्तर पूर्व भारतात, विशेषतः आसाम आणि अरुणाचल प्रदेश ह्या भागात हे वृक्ष आढळतात.  बिहार, बंगाल, मध्य प्रदेश, महाराष्ट्र, आणि उत्तराखंड ह्या राज्यात काही वृक्ष अजूनही आहेत.  महाराष्ट्रात कोकणातील जंगलात हा वृक्ष काही ठिकाणी आढळतो.  भारतात काही ठिकाणी ह्या वृक्षाची लागवड करण्याचा प्रयत्न झाला आहे.

ह्या वृक्षांसाठी उपयुक्त वातावरण
दमट उष्णकटिबंधीय हवामानात हे वृक्ष वाढतात.  २० ते ३० अंश तापमान आणि वर्षभरात २००० ते ४५०० मिलीमीटर पाऊस असलेल्या भागात हे वृक्ष चांगले वाढतात.  
गरम प्रदेशात वाढलेल्या ह्या वृक्षांना फळे येत नाहीत.  

पाने व फुले
पाने वरून चमकदार हिरव्या रंगाची आणि खालून गडद हिरव्या रंगाची असतात.  वास नसलेली पाने हलक्या कडू चवीची असतात.  पाने ६ ते ८ सेंटीमीटर रुंद व १८ ते २० सेंटीमीटर लांब असतात.  पानं पिकल्यावर लाल होतात.
झाड सात ते आठ वर्ष वाढल्यानंतर फुले यायला सुरुवात होते.  एप्रिल आणि मे महिन्यात पांढऱ्या किंवा पिवळ्या रंगाची फुले येतात.

फळे
साधारणतः जून महिन्यात ह्या झाडांना फळे येतात.  एका झाडाला एका मोसमात एक हजार ते दोन हजार फळे येतात.  ऑगस्ट ते ऑक्टोबर च्या सुमारास फळे पिकतात.  गोल किंवा अंडाकृती आकाराची फळे कच्ची असताना हिरव्या रंगाची असतात.  पिकल्यावर निळसर किंवा जांभळ्या किंवा तपकिरी किंवा राखाडी रंगाची बनतात.  फळाची साल टणक दगडासारखी दिसणारी असते.  फळांच्या आत आंबट चवीचा गर असतो.  फळाच्या मधोमध बिया असतात.  बियांच्या संरक्षणासाठी कडक आवरण असते.  बिया आणि त्यांच्यावरचं कडक आवरण म्हणजे रुद्राक्ष.  रुद्राक्षाचा आकार मटारच्या दाण्यापासून अक्रोडाएवढा असतो.  रुद्राक्षाच्या आत जे कप्पे असतात त्यात बिया असतात.  ठिकाण आणि वातावरण जसे असेल त्या प्रमाणे रुद्राक्ष बनतात.  रुद्राक्षावर असलेल्या भागांनुसार तो किती मुखी आहे ते ठरते.  रुद्राक्ष १ ते २१ मुखी असतात.  ४ मुखी, ५ मुखी, आणि ६ मुखी रुद्राक्ष सगळ्यात जास्त संख्येने आढळतात.  हिमालयाच्या पायथ्याशी असलेल्या भागातील रुद्राक्ष उत्तम प्रतीचे मानतात.  बहुतेक रुद्राक्ष तपकिरी रंगाचे असतात.  क्वचित एखादा पांढरा, लाल, पिवळा, किंवा काळा असू शकतो.  रुद्राक्षामध्ये इलेक्ट्रोमॅग्नेटिक गुणधर्म असतात.  रुद्राक्ष हा संस्कृत शब्दाची फोड रुद्र आणि अक्ष अशी होईल.  रुद्र हे शंकराचे एक नाव असून अक्ष म्हणजे डोळे.  रुद्राक्षांना शंकराचे डोळे असे म्हटले आहे.

संदर्भ
१. प्रतीक्षा आर्यल (२०२१),  Medicinal value of Elaeocarpus sphaericus: A review
२. पंत मनू, अंकिता लाल, राणी अंजु (२०१३),  Elaeocarpus sphaericus: A Tree with Curative Powers: an Overview

स्वप्न म्हणजे नेमकं काय

शाळेत असताना कधी वाटायचं दूर दूर जाऊन सगळीकडे फिरावं.  विहिरीतल्या बेडकासारखं एका जागी राहू नये.  ऊन पाऊस वाऱ्याला घाबरू नये.  ज्या देशात जन्म घेतलाय तो देश फिरून बघावा.  इतिहासाच्या मारकुट्या आणि भूगोलाच्या रागीट चिडक्या शिक्षकांच्या पलीकडे जाऊन हे विषय खरे काय आहेत ते बघावे.

समोर येईल तो डोंगर चढून जावा.
आपल्यासारखेच चार मित्र भेटावे जे तहान भूक विसरून आपल्याबरोबर दिवसभर फिरतील.
जगाला फाट्यावर मारून स्वतःला हवं तसं जगावं.
उंचावरच्या भिंतींवर धिटाईने आरामात बसावं.
ज्या भागात गेलोय तो पूर्ण प्रदेश पालथा घालावा.  मग एकेक गोष्टी सापडत जाव्या.  पाडलेली देवळं, भंगलेल्या मुर्त्या, वाड्यांचे अवशेष, मध्ययुगीन पायविहिरी.
इतिहासाच्या पुस्तकापलीकडचा ह्या देशाचा खरा इतिहास उलगडत जावा.
गावं शहरं रस्ते गल्ल्या धुंडाळत फिरावं.
प्लॅन मध्ये नसलेल्या पण जरा वेगळ्या जागा दिसल्या तर थांबावं.
ज्ञात अज्ञात सगळ्या जागा पाहता याव्या.  जे पाहतो ते काय आहे तिथे का आहे हे जाणून घ्याची इच्छा असावी.
तोफा बुरुज चोरवाटा बघताना चतकोर हत्तीचं बळ मिळावं.
एखाद्या डोंगरकपारीत दोन घटका विश्रांती घ्यावी.  घळीतलं थंडगार पाणी प्यावं.
कधी अचानक एखाद्या जागी दगडी तोफगोळे सापडावे.
माझ्या देशातल्या समृद्ध आणि विविधतेने नटलेल्या परंपरा फक्त प्रतिज्ञेपुरत्याच न राहता त्यांना समजून घेण्याचा प्रयत्न करावा.
दिवसभराच्या शोधमोहीमेनंतर शांतपणे धरणाच्या भिंतीवर बसावं.  तिथे सूर्य डोंगराआड जावा.

असं म्हणतात कि प्रत्येक कुत्र्याचा एक दिवस येतोच.  काहींना कमी वाट पाहावी लागते तर काहींना जास्त. 

समोर येईल तो डोंगर चढून जावा

आपल्यासारखेच चार मित्र भेटावे जे तहान भूक विसरून आपल्याबरोबर दिवसभर फिरतील

 

जगाला फाट्यावर मारून स्वतःला हवं तसं जगावं

उंचावरच्या भिंतींवर धिटाईने आरामात बसावं

 

ज्या भागात गेलोय तो पूर्ण प्रदेश पालथा घालावा.  मग एकेक गोष्टी सापडत जाव्या.  पाडलेली देवळं, भंगलेल्या मुर्त्या, वाड्यांचे अवशेष, मध्ययुगीन पायविहिरी.

इतिहासाच्या पुस्तकापलीकडचा ह्या देशाचा खरा इतिहास उलगडत जावा

 

गावं शहरं रस्ते गल्ल्या धुंडाळत फिरावं

 

प्लॅन मध्ये नसलेल्या पण जरा वेगळ्या जागा दिसल्या तर थांबावं

 

ज्ञात अज्ञात सगळ्या जागा पाहता याव्या.  जे पाहतो ते काय आहे तिथे का आहे हे जाणून घ्याची इच्छा असावी.

तोफा बुरुज चोरवाटा बघताना चतकोर हत्तीचं बळ मिळावं.

 

एखाद्या डोंगरकपारीत दोन घटका विश्रांती घ्यावी.  घळीतलं थंडगार पाणी प्यावं.

 

कधी अचानक एखाद्या जागी दगडी तोफगोळे सापडावे.

माझ्या देशातल्या समृद्ध आणि विविधतेने नटलेल्या परंपरा फक्त प्रतिज्ञेपुरत्याच न राहता त्यांना समजून घेण्याचा प्रयत्न करावा.

 

दिवसभराच्या शोधमोहीमेनंतर शांतपणे धरणाच्या भिंतीवर बसावं.  तिथे सूर्य डोंगराआड जावा.

 

ठिकाण, वेळ, नाव, गाव, फळ, फुल कोणतं आहे, काय फरक पडतो? आपण समाधानी असलो तर भरून पावलो.  त्यामुळे राहून राहून ह्या चार ओळी आठवतात.  
माला फेरत जुग भया
फिरा न मन का फेर,
कर का मनका डारि दे
मन का मनका फेर।
हातात जपमाळ घेऊन तासनतास जपजाप्य करताना देखील ऐहिक गोष्टींपलीकडे मनाचा आवाका जात नाही.  देव्हाऱ्यासमोर पूजा चालू असते पण सूनबाई मुलाशी काय खुसरपुसर करते तिकडे कान टवकारलेले असतात.  नातवंडे काय उद्योग करून ठेवत आहेत, कामवाल्या बाईने भांडी नीट घासली की नाही, नवऱ्याचे जिभेचे चोचले आज योग्य प्रकारे पुरवले कि नाही, असे विचार मनात येत राहतात.  मंदिरात हात जोडताना बाहेर ठेवलेली चप्पल कोणी चोरणार नाही ना, याची चिंता वाटत असेल तर त्या भक्तीला कसला आला आहे भाव.  माळ फिरवताना देखील त्यांच्या मनोभूमिकेत काडीचा फरक आढळत नाही.  म्हणून कबीर सांगून गेला,
"माला फेरत जुग भया, फिरा न मन का फेर"  हातात जपमाळ आणि मनात कचरा ठासून भरलेला असेल, डोक्यात नको ते विचार थैमान घालत असतील तर असा जप केला काय आणि नाही केला काय, कसला फरक पडणार आहे?
"कर का मनका डारि दे"  हातातली जपाची माळ टाकून दे, "मन का मनका फेर" मनाचा मणी फिरव.
पद्धत कशी का असेना, हे जमलं तर भरून पावलो.

मी पाळलेले मांजर

खुशी लहान होती तेव्हा कधीतरी "आपण एक प्राणी पाळूया ना", "आपण एक मांजर पाळूया ना", "आपण एक कुत्रा पाळूया ना" असे प्रश्न विचारायची.  त्या प्रश्नांना मला स्थळ-काळानुसार समर्पक उत्तरं द्यावी लागत.  शहरातल्या फ्लॅट मधे प्राणी पाळायचा हे मला कधी पटले नव्हते.  प्राणी पाळला तर त्याची जबाबदारी माझ्यावरच येणार हे मी ओळखून होतो.  आणि प्राणी पाळण्यासाठी माझ्याकडे वेळ नव्हता.  वेळ नव्हता यापेक्षा ते करण्याची तयारी नव्हती.  आणि आपल्यामुळे त्या बिचाऱ्या मूक प्राण्याला त्रास होणार असं मला होऊ द्यायचे नव्हते.  पण कोणीतरी कुठेतरी म्हणून ठेवलंय, "प्रत्येक गोष्टीची एक वेळ असते".  ती वेळ येईपर्यंत कितीही काही खटपट केली तरी आपलं काही चालत नाही.  आणि ती वेळ आली कि ती गोष्ट तुमच्यापर्यंत चालत येते.  जणू काही तुमचा त्यात काहीच भाग नाही.

मागच्या महिन्यातला, म्हणजे एप्रिलचा पहिला आठवडा.  उन्हाळ्याने टोक गाठलेलं.  तशात लॉकडाउन पुढ्यात दिसायला लागलेलं.  शहरातल्या बागा, मैदानं वगैरे ठिकाणं नुकतीच बंद झालेली.  त्यामुळे सकाळचं रनिंग बंद.  दिवसभर घरी बसून करायचं काय, हाच मागच्या वर्षीचा जुना प्रश्न पुन्हा नव्याने पुढे आलेला.  एका सकाळी कचऱ्याची पिशवी टाकण्यासाठी मी दार उघडलं.  दाराच्या पुढ्यात एक मांजराचं पिल्लू होतं.  ते पळत घरात आलं.  मी काही प्रतिक्रिया द्यायचा आधीच पळत पुढे गेलं.  त्याच्या मागे मी.  ते थेट खुशीच्या रूम मधे शिरलं.  उन्हाळी सुट्ट्यांमध्ये सकाळी अंथरूणात लोळत पडणारी खुशी "मांजर आलंय" असं मी सांगितल्यावर एका सेकंदात उठली.

खुशीला मांजराचं पिल्लू हवंच होतं.  पिल्लू घरात सगळीकडे फिरायला लागलं.  त्याला आम्ही खायला दिलं.  पिल्लू फारच निरागस गोड होतं.  त्याला परत खाली नेऊन सोडायचा प्रश्नच नव्हता.  आमचा अख्खा दिवस पिल्लाच्या मागे.  त्याला काय खायला पाहिजे.  ते कसं खेळतंय.  कुठून कशा उड्या मारतयं.  रात्री पिल्लाला भूक लागली.  ते ओरडायला लागलं.  त्याला काय खायला द्यायचं कळेना.  थोडं सुकट दिलं.  ते खाऊन त्याला अजून हवं झालं.  चार वेळा सुकट खाल्यावर त्याची भूक भागली.  रात्री खुशी पिल्लाला बरोबर घेऊन झोपली.

सकाळी उठल्यावर पिल्लाने दीप्तीच्या पायावर अंथरुणातच शी केली.  त्याला शी ची सवय कशी लावायची हा प्रश्न अजून सुटला नव्हता.  झाड न लावलेली एक कुंडी हा आमचा उपाय तितकासा लागू पडला नव्हता.  आमचे पुढचे दोन दिवस पिल्लाच्या मागे गेले.  पिल्लू घरात सगळीकडे चौकसपणे दिवसभर हिंडलं फिरलं.  उड्या मारून खेळलं.  त्याला योग्य सवयी लावण्यासाठी आम्ही त्याच्या मागे.  किचन प्लॅटफॉर्म आणि डायनिंग टेबल ह्या दोन ठिकाणी बिलकुल चढायचं नाही.  ताटलीत दिलेलं खायचं.  आम्ही जेवत असताना ताटात यायला बघायचं नाही.  पिल्लू पटापट शिकलं.  पण शी आणि शु चा प्रश्न सुटत नव्हता.  छोटी कुंडी पिल्लाला फारशी आवडली नव्हती.  रोज बेडशीट धुवाव्या लागत होत्या.  शु करण्यासाठी बीन बॅग हि त्याची आवडती जागा होती.  शेवटी कंटाळून मी आणि दीप्तीने जवळच्या पेट शॉप मधून सॅण्ड पिट आणि सॅण्ड आणली.  हा उपाय प्रभावी ठरला.

जवळच्या पेट शॉप मधून मी मांजराचं खाणं आणलं.  खुशीने पिल्लाचे कान साफ केले.  भूक लागल्यावर पिल्लाला खायला मिळायला लागलं.  "काय नशीब फिरलं ह्याचं.  आत्ता पर्यंत पार्किंग मधे धुळीत रहात होतं.  झुरळं वगैरे काय मिळेल ते खात होतं.  आणि आता बघा.  भूक लागली कि आयतं खायला मिळतंय.  मजेत ताणून झोपायला मिळतंय."  इति दीप्ती.

सर्वेशने पोलिसांना लिहिलेले पत्र केदारने मला WhatsApp वर पाठवलं होतं.

 मी त्या पत्राला उत्तर लिहिलं. 

UTF-8 : Where Ινδία is bigger than India

A peculiar problem was once reported by a customer of our data storage product.
They were copying files from a Netapp solution to their newly setup IBM Storwize V7000 Unified system.
Many files were having names with Greek characters in them.  Some of those had really long names.
Files whose names were Greek and longer than 125 characters failed to copy.
Being the Linux flag bearer, the issue came my way.

My investigation involved checking all the possibilities of where the issue could be.  I wanted to check all the possibilities.  Robocopy, the tool used for copying the files.  Samba, the protocol used for copying the files.  The locale being used at the Unified system.  Since we use RHEL in IBM Storwize V7000 Unified system, I had opened a dialogue with Red Hat as well.

Investigation converged to the limit of file names as defined by the operating system in use, Linux, and file system in use, GPFS.  255 bytes was the limit in case of both.  In case of Linux, this came from NAME_MAX macro in limits.h header.

     #define NAME_MAX         255    /* # chars in a file name */

RHEL and GPFS both were using UTF-8 encoding for file names.  UTF-8 requires 2 bytes for storing one Greek character.  Hence files whose names were longer than 125 Greek characters were failing to copy.

 

Someday I want to do this experiment.  Update the NAME_MAX macro in limits.h and recompile, so that files having longer names could see light of the day.