Recently I am developing a feature where I need to protect a file from all users including the root. Most of the kernels do this by restricting the permissions stuff and/or attaching some special flags with the files notifying that this file should not be touched. While shaving this morning, I had a weird idea.
I want to protect a file, so restricting the permissions to root is an obvious thing to do here. But still root can modify this file. If I want to block root user as well, what if I had an another internal root like user? This would also be a root user, say a root cousin which is invisible to outside world. So in this case, root can read the file but can not modify it. I know this breaks the standard UNIX legacy we have that there is only one powerful god and that is root. What if we shatter this? There would be more than one god, so would there be a clash of titans? No, the rule is one god does not interfere with other god. The gods are read-only while interfering with another god. In this case, it gives an impression that root user is not able to modify certain file. Since internally this file is owned by root cousin, root is not able to change/modify it. So the change of behavior is quite noticeable. I don't know if this would be acceptable.
Since this root cousin is invisible to end user, he/she can not inherit root cousin privileges. And a root user can not change/modify the files that need to be protected.
This is a very simple idea and might have occurred to a lot of people. The moment I struck it, I felt like noting it down somewhere and thats why I am posting it here. I still need to figure out how to implement this. Will update about it soon.
Few basics on how to implement this. This root cousin needs a dedicated uid and gid at least for UNIX. This uid and gid can not be used by end user. Kernel uses this identifiers for its own protection. So there is no way an end user can make a file owned by root cousin. Only the kernel is able to use these dedicated uid and gid in order to protect some files even from root. So it is quite obvious that we should not use these root cousin privileges everywhere. Rather, its use should be kept to minimal. For files, we don't want even root to change/modify, we should make them own by root cousin. While displaying the file properties (ls command), should we display the dedicated uid and gid for root cousin or should we show root uid and gid instead? If we show root uid and gid, the end user will still have the illusion that these files are owned by root but they can not be changed/modified. Great!! This goes well with the UNIX methodology. Lots of questions are popping in my head. Will update again as I have more answers.
Thursday, July 17, 2008
Thursday, July 10, 2008
This is not easy
Today we had the pleasure to listen to a talk from a reputed personality Dr Deepak Phatak from IIT-Bombay at our company. For those who don't know, Dr Phatak is an honorable name in Computer Science in India and abroad. He is known for his contribution to Databases, Information Systems and Software Engineering. Today's topic was Innovation. In precise words, Dr Phatak told the basics of living life. Few key things of his talk are summarized here. The things mentioned below are as per my perspective. If I have misinterpreted Dr Phatak somehow, that is totally a fault of mine. Please step up to correct things if so.
1. Always keep learning : Since early schooling, the students are groomed to mug up the study materials and throw it up in the exams. In this way, we kill the creativity in ourselves. Another important point he raised is to ask questions. Even I have observed that most of us are scared to ask a question in public or more over scare to question something that is going on for ages. Dr Phatak strongly recommended to question the orthodox, conventional methods. Even if it is right, that will satisfy your conscious. Statistics does not always interpret a person completely. Each person is unique in its own way. What matters is his/her thinking line and not his statistics.
2. Don't kill the child (curiosity) in you : As a child is always curious about everything, he is eager to know why certain things are the way they are. Dr Phatak suggested that we should keep alive the curiosity in ourselves. This curiosity will help us find answers to questions that we face. And sometimes, it helps us find better answers that can be categorized as Innovation. So we need to make a habit of being curious so that at least we can answer our own questions. in my opinion, every person has a fear of unknown and this curiosity will definitely help in overcoming this fear. Another point Dr Phatak raised is not to compartmentalize knowledge. Most of us, even I do the same, we try to categorize problems as per their domains like automobiles belong to mechanical engineering, operating systems belong to computer science and so forth. This would have a negative impact on our learning approach. Dr Phatak encouraged to treat every thing as same and not categorize them as per their domains. This will help us to learn about everything around us and not only our domains.
3. Think different : According to Dr Phatak, most of the individuals tend to behave like ox-cart bullocks in a sense that they only know to walk a known path. They do not dare to venture on an unknown path. Came a certain problem, this is the way to solve it, this is their approach. Dr Phatak strongly encouraged to align your thinking patterns on different lines. Conventional wisdom is not always right or rather appropriate to solve certain problems. People who go out of the way, those who think different can make things happen. This does not apply only to Computer Science but to each and every field.
4. Passion for work : In order to innovate, one must have passion that is the driving factor for your thing to work. Without passion, there would be no energy, no enthusiasm in your venture. Only passion can keep alive your venture in rough times. In short, without passion, your venture will be like a body with no soul.
5. Persistence and commitment : Started a venture, persistence and commitment are another properties that can lead it to completion. Like they say, starting a venture is very easy but grooming it, maintaining it is very difficult. Hardwork is definitely a part of life but it is only with persistence and commitment, it can survive your venture.
After listening to Dr Phatak's speech, I realized that he has pointed the very basic things that we have conveniently forgotten. As for myself, by this time, I know what my flaws, my weak points are (not all of them) and I am trying to over come them. But it has been very difficult so far. With the points Dr Phatak mentioned, I think I need to go back to basics. If you build a strong foundation, the structure will thrive.
Saturday, May 31, 2008
Deduplication anyone?
De duplication is one of the hot topics in storage world. With tons of vendors offering de dup products and biggies like Netapp offering integrated de dup solutions with their NAS products, the competition is fierce. How does du duplication help when actually the consumer is trying to keep redundant data in order to facilitate disaster recovery?
Effectively de dup is doing opposite of what RAID, replication, snap shots do. This is not exactly how it sounds. The de dup essentially tries to take a whole different approach in order to save disk space on a file system. The granularity of de dup could be a file or a file system block. If done at file level, it would de dup less data since very few times are two files are entirely identical. But blocks could be identical very often and it would definitely save more space. We would discuss block based de dup here.
- De dup calculates a kind of identity signature for each block on the file system and stores it with a data base. Now the blocks containing the same data will generate same signature and can be detected to be a duplicate of an existing block. A cryptographic hash algorithm like MD5 or SHA1 can be used to generate this signature.
- How to store these signatures, that is the layout of database storing these signatures is highly platform dependent. The main requirement from this database is to give a list of blocks generating same signature (having same data), something like a hash bucket storing all elements generating same hash value.
- Another important requirement is that de dup should work while the file system is online. Putting the file system off line is not an option. Hence if write comes on a block for which signature has been stored with the data base needs to regenerate the signature in order to keep up with the latest data. This definitely needs a trap in the IO path but it should be such that it should have a minimal impact on the IO performance.
- Please keep in mind that de dup will only de dup the data blocks and not the meta data. Meta data is duplicated on purpose and should not be touched.
- So for the very first time de dup is started, it will generate signatures for all the data blocks in the file system. Once this pass is finished, we have all the information in the data base. Traversing this data base will give us a list of blocks bearing same data.
- For these blocks, only one copy can be kept while other blocks will be freed and the meta data of freed blocks will point to the one copy.
- One side effect of de duplication is that the next time a write comes on some block, we need to know if this block is sharing data with some other data. If it is, we need to do a copy-on-write here. Basically we allocate new block, write data on the new block and update meta data of the block. This way, the writes might have to bear a read penalty.
- For file systems which have copy-on-write in IO path like WAFL and ZFS, this would be not a problem. Other file systems would have to bear this penalty.
- Getting the data base in core is another problem. Either it needs to be implemented as cache otherwise it will occupy a lot of space. This would be very implementation specific.
Any more thoughts?
Update : Curtis Preston explains this in a very simple manner. Have a look at this - http://www.backupcentral.com/content/view/175/47/
Effectively de dup is doing opposite of what RAID, replication, snap shots do. This is not exactly how it sounds. The de dup essentially tries to take a whole different approach in order to save disk space on a file system. The granularity of de dup could be a file or a file system block. If done at file level, it would de dup less data since very few times are two files are entirely identical. But blocks could be identical very often and it would definitely save more space. We would discuss block based de dup here.
- De dup calculates a kind of identity signature for each block on the file system and stores it with a data base. Now the blocks containing the same data will generate same signature and can be detected to be a duplicate of an existing block. A cryptographic hash algorithm like MD5 or SHA1 can be used to generate this signature.
- How to store these signatures, that is the layout of database storing these signatures is highly platform dependent. The main requirement from this database is to give a list of blocks generating same signature (having same data), something like a hash bucket storing all elements generating same hash value.
- Another important requirement is that de dup should work while the file system is online. Putting the file system off line is not an option. Hence if write comes on a block for which signature has been stored with the data base needs to regenerate the signature in order to keep up with the latest data. This definitely needs a trap in the IO path but it should be such that it should have a minimal impact on the IO performance.
- Please keep in mind that de dup will only de dup the data blocks and not the meta data. Meta data is duplicated on purpose and should not be touched.
- So for the very first time de dup is started, it will generate signatures for all the data blocks in the file system. Once this pass is finished, we have all the information in the data base. Traversing this data base will give us a list of blocks bearing same data.
- For these blocks, only one copy can be kept while other blocks will be freed and the meta data of freed blocks will point to the one copy.
- One side effect of de duplication is that the next time a write comes on some block, we need to know if this block is sharing data with some other data. If it is, we need to do a copy-on-write here. Basically we allocate new block, write data on the new block and update meta data of the block. This way, the writes might have to bear a read penalty.
- For file systems which have copy-on-write in IO path like WAFL and ZFS, this would be not a problem. Other file systems would have to bear this penalty.
- Getting the data base in core is another problem. Either it needs to be implemented as cache otherwise it will occupy a lot of space. This would be very implementation specific.
Any more thoughts?
Update : Curtis Preston explains this in a very simple manner. Have a look at this - http://www.backupcentral.com/content/view/175/47/
Monday, February 25, 2008
What would you prefer?
Was just thinking about what a person would chose in case he/she wants to chose certain thing? The choices are
- a clean design, sturdy, effective system but with limited functionality,
- a system clogged with features but not that effective (sewn bits n pieces together)
Lets call the first system system1 and next one system2.
The answer clearly depends on a number of factors. The need of consumers is the driving factor. Thus even if most of us would favor the clean design system, in practical life, the system2 might be useful/effective. I would favor the clean design system as well. The ideology is to build a good foundation and use the outputs of this foundation to develop new things. The same way a building is constructed or code is (should be) written. Because such systems are easier to maintain, easy to reuse and sturdy. On the other hand, the system2 is usually not good as a standalone system, neither can it scale very well. It can lead to unused code/resources and clog up your workspace. It can make your system heavy, verbose and might lose the very cause of its own existence.
Even after starting with a clean design, keeping it clean is the toughest job. A focused team of engineers can do the job better than a thousand people be it software or any other field for that matter. In short, keeping integrity of the project while dealing large number of people really becomes hard. It takes hard work, enthusiasm and innovative mind to keep up the integrity of the project. Thats why startups succeed and are able to do things that might take big corporations a lot of time and a lot of money.
- a clean design, sturdy, effective system but with limited functionality,
- a system clogged with features but not that effective (sewn bits n pieces together)
Lets call the first system system1 and next one system2.
The answer clearly depends on a number of factors. The need of consumers is the driving factor. Thus even if most of us would favor the clean design system, in practical life, the system2 might be useful/effective. I would favor the clean design system as well. The ideology is to build a good foundation and use the outputs of this foundation to develop new things. The same way a building is constructed or code is (should be) written. Because such systems are easier to maintain, easy to reuse and sturdy. On the other hand, the system2 is usually not good as a standalone system, neither can it scale very well. It can lead to unused code/resources and clog up your workspace. It can make your system heavy, verbose and might lose the very cause of its own existence.
Even after starting with a clean design, keeping it clean is the toughest job. A focused team of engineers can do the job better than a thousand people be it software or any other field for that matter. In short, keeping integrity of the project while dealing large number of people really becomes hard. It takes hard work, enthusiasm and innovative mind to keep up the integrity of the project. Thats why startups succeed and are able to do things that might take big corporations a lot of time and a lot of money.
Saturday, December 22, 2007
How about a cluster File System???
Was just speculating about what exactly would I need, if i have to write a cluster file system? First, let us throw some light on the requirements. The file system needs to provide reliable storage, should support multiple read writes simultaneously, good performance and one of the most important fault tolerant.
A cluster friendly file system basically needs a fine grained and efficient Distributed Lock Manager, transport level protocols that support range locking, namely NFSv4 and CIFS and moreover it needs a cluster protocol to manage operations across nodes. Usually this cluster protocol runs over high speed networks like Infiniband, Gigabit ethernet (still slower), fiber channel so as to enhance the throughput.
A cluster is built for the purpose of high performance computing. So if the IO throughput is not good, it serves no purpose to build a cluster. How I see a cluster is a collection of bunch of machines working together under certain code to gain higher throughputs and thus reflecting one entity as a whole. So this would fit perfectly to a collection of commodity computers. I am not talking about custom build rack mounted clusters.
Basically IO throughput is enhanced using striping the data across all nodes in the cluster. This way we can do a parallel read/writes and read aheads. Even if this increases the amount of meta data that needs to be maintained for a file, it increases the throughput on a larger scale. Most of the existing clusters including the google file system, luster implement same techniques.
A good light weight Distributed Lock Manager would help in minimizing the locking periods across files. Major files operations lock the parent directory. So fine grained locking would help to keep contention at the lowest possible level.
But making the cluster fault tolerant is one heck of a task. Say, while watching a movie over the cluster, if the next frame is unavailable, the movie player will halt waiting for the frame. The catch is to get the data within limits of application time out. If the backend is built with RAID, the application has to wait until RAID rebuild is complete. And this time is too big and the application will time out for sure. So how to solve this problem? There is no definite answer here. Only thing we can possibly do is to take a top down approach and build a framework to support data losses. These strategies include RAID (for data regeneration in case of losses), CRCs to detect corruptions etc. Still not fool proof :(
Managing data losses/outages is a tricky question and not completely answered. If the cluster is serving a data intensive application with utter need of uptime, probably keeping a copy of data would serve the purpose. This is a hell lot space inefficient but would save you time for sure. The other option is going the RAID way. RAID is built to be space efficient but the RAID rebuilds are really inefficient in practical life.
A cluster friendly file system basically needs a fine grained and efficient Distributed Lock Manager, transport level protocols that support range locking, namely NFSv4 and CIFS and moreover it needs a cluster protocol to manage operations across nodes. Usually this cluster protocol runs over high speed networks like Infiniband, Gigabit ethernet (still slower), fiber channel so as to enhance the throughput.
A cluster is built for the purpose of high performance computing. So if the IO throughput is not good, it serves no purpose to build a cluster. How I see a cluster is a collection of bunch of machines working together under certain code to gain higher throughputs and thus reflecting one entity as a whole. So this would fit perfectly to a collection of commodity computers. I am not talking about custom build rack mounted clusters.
Basically IO throughput is enhanced using striping the data across all nodes in the cluster. This way we can do a parallel read/writes and read aheads. Even if this increases the amount of meta data that needs to be maintained for a file, it increases the throughput on a larger scale. Most of the existing clusters including the google file system, luster implement same techniques.
A good light weight Distributed Lock Manager would help in minimizing the locking periods across files. Major files operations lock the parent directory. So fine grained locking would help to keep contention at the lowest possible level.
But making the cluster fault tolerant is one heck of a task. Say, while watching a movie over the cluster, if the next frame is unavailable, the movie player will halt waiting for the frame. The catch is to get the data within limits of application time out. If the backend is built with RAID, the application has to wait until RAID rebuild is complete. And this time is too big and the application will time out for sure. So how to solve this problem? There is no definite answer here. Only thing we can possibly do is to take a top down approach and build a framework to support data losses. These strategies include RAID (for data regeneration in case of losses), CRCs to detect corruptions etc. Still not fool proof :(
Managing data losses/outages is a tricky question and not completely answered. If the cluster is serving a data intensive application with utter need of uptime, probably keeping a copy of data would serve the purpose. This is a hell lot space inefficient but would save you time for sure. The other option is going the RAID way. RAID is built to be space efficient but the RAID rebuilds are really inefficient in practical life.
Monday, October 29, 2007
Virtualization wave???
Server virtualization is on the rise. Virtual Machines (VM) does hold their ground when compared to high performing hardware. Just add some more main memory and some disk space to your existing machine and you are able to run a new instance of another operating system. How about running vmware on a big massive hardware like Sun Niagara T2 or a rack of Intel Quad-core CPUs?
How about an organization that wants to scale up the operations and needs bigger hardware to support it? It would definitely go for a combination of both, buying fewer racks of hardware than needed and may be running VMs on it. Suppose it buys few big big n-core CPUs with support for virtualization. Still fulfilling all your needs from one physical machine gives rise to single point of failure. May be spreading your VMs logically over a farm of servers would help. It eliminates single point of failure, still availing all benefits of a VM. The biggest benefits I see are power savings, back up, security and seamless upgrades. VM running from one machine would not consume power beyond a limit. The host images could be backed up regularly. By nature, VMs are secure and would not spread the defect to the host if contaminated by worms/virus. And the most important of it, upgrades!!!!!
Upgrades seem to be essential part of IT operations of an organization. To keep up with the pace of ongoing progress of hardware, an organization would buy new hardware every few years. For hardware whose support has been discontinued, it is really hard to find a replacement. And data needs to be migrated manually which is a cumbersome process. Here a VM wins hands on with a hardware machine. Moreover, I think if multiple VMs are running same image of operating system, it is quite possible to share disk space from a nas exported file system. Essentially, force all VMs running the same operating system to mount a nas exported file system and share the same image with all other VMs. I suppose, a file system with a good distributed lock manager and support for snapshots would be able to support such circumstances. Just imagine how much space we would be saving!! Moreover, this is somewhat like deduplication (in essence, not by implementation), where the common data is shared while individual changed data is there and kept track with the help of file system snapshoting mechanism. What we have here is essentially a lethal combination!!! :)
There is in-built NFS support from vmware but I don't know what other features do they provide along with. I guess, both Vmware and Xen supports most of these facilities. Vmware owned by EMC recently released 10% of its shares and it almost doubled within few hours. Xen was also acquired by Citrix. I am wondering about the upcoming trends in virtualization!!!
Update : Intel recently announced their own virtualization initiative based on Xen. And Vmware stock dropped on the news while Oracle's rose!!!
How about an organization that wants to scale up the operations and needs bigger hardware to support it? It would definitely go for a combination of both, buying fewer racks of hardware than needed and may be running VMs on it. Suppose it buys few big big n-core CPUs with support for virtualization. Still fulfilling all your needs from one physical machine gives rise to single point of failure. May be spreading your VMs logically over a farm of servers would help. It eliminates single point of failure, still availing all benefits of a VM. The biggest benefits I see are power savings, back up, security and seamless upgrades. VM running from one machine would not consume power beyond a limit. The host images could be backed up regularly. By nature, VMs are secure and would not spread the defect to the host if contaminated by worms/virus. And the most important of it, upgrades!!!!!
Upgrades seem to be essential part of IT operations of an organization. To keep up with the pace of ongoing progress of hardware, an organization would buy new hardware every few years. For hardware whose support has been discontinued, it is really hard to find a replacement. And data needs to be migrated manually which is a cumbersome process. Here a VM wins hands on with a hardware machine. Moreover, I think if multiple VMs are running same image of operating system, it is quite possible to share disk space from a nas exported file system. Essentially, force all VMs running the same operating system to mount a nas exported file system and share the same image with all other VMs. I suppose, a file system with a good distributed lock manager and support for snapshots would be able to support such circumstances. Just imagine how much space we would be saving!! Moreover, this is somewhat like deduplication (in essence, not by implementation), where the common data is shared while individual changed data is there and kept track with the help of file system snapshoting mechanism. What we have here is essentially a lethal combination!!! :)
There is in-built NFS support from vmware but I don't know what other features do they provide along with. I guess, both Vmware and Xen supports most of these facilities. Vmware owned by EMC recently released 10% of its shares and it almost doubled within few hours. Xen was also acquired by Citrix. I am wondering about the upcoming trends in virtualization!!!
Update : Intel recently announced their own virtualization initiative based on Xen. And Vmware stock dropped on the news while Oracle's rose!!!
Thursday, August 16, 2007
Sun Niagara T2
Sun recently launched a new chip, named Niagara UltraSparc T2. T2 posses tremendous processing power packed in. It has 8 cores on die, each capable of holding 8 threads at a time. There is a dedicated FPU per core. Some features worth mentioning are - bigger L2 cache, on die 10Gbps NIC, virtualization support, on die PCI Express lanes, a crypto unit per core and 4 memory controllers. Since each core can hold 8 threads simultaneously, where other CPUs would make a context switch, T2 would save time. Those features make T2 a pretty obvious target for computing power hungry applications.
Sun has been pushing this chip to market as a commodity so that it can be used for general purposes like - big data centers, financial services (will benefit from the on-die crypto unit), web services, big telcos and proprietary solutions. It is quite evident that Sun MicroElecronics division has traded higher CPU cycles for low power consumption. T2 runs on a rather low CPU frequency of 1.4 GHz where the competition is running processors worth 3-4GHz fast. Clearly, Sun has pushing parallel computing as much as possible since this approach consumes low power by having a low frequency CPU while using all possible benefits of parallel computing.
As of now, this approach seems to be a winner. T2 is safely ahead of competition in terms of throughput, power consumption and efficiency. And it is currently leading the SPEC benchmarks. Interesting thing is to see if Sun can keep this lead. Intel n AMD are in the process of rolling out their quad-core CPUs to market shortly. Also running a low frequency CPU, it would be interesting to see single thread performance on T2.
Sun has to really push this chip so as to pursue customers to adopt this Sparc chip instead of their usual x86 setups.
Sun is planning to introduce the next processor named Rock in next year. It would be an excitement to see what improvements does Sun bring into the new processor over T2. Sun also claims Solaris has been successfully run on T2. Using Solaris along with ZFS on T2 would be a killer combination as of now. Eagerly waiting for the first official Sun launch of a storage box based on T2.
P.S. A new MIT startup has announced its new chip Tilera, a 64 core processor with features same as US T2, likewise, on chip DIMM, gbps NICs, PCIe lanes etc. It provides a mesh of cores, which serves as an alternative for high speed bus interconnect. The clock cycles are within the range 600MHz - 900MHz. It usually takes one cycle to move data from one core to another. Would be nice to see a comparision benchmark of Tilera against US T2.
Sun has been pushing this chip to market as a commodity so that it can be used for general purposes like - big data centers, financial services (will benefit from the on-die crypto unit), web services, big telcos and proprietary solutions. It is quite evident that Sun MicroElecronics division has traded higher CPU cycles for low power consumption. T2 runs on a rather low CPU frequency of 1.4 GHz where the competition is running processors worth 3-4GHz fast. Clearly, Sun has pushing parallel computing as much as possible since this approach consumes low power by having a low frequency CPU while using all possible benefits of parallel computing.
As of now, this approach seems to be a winner. T2 is safely ahead of competition in terms of throughput, power consumption and efficiency. And it is currently leading the SPEC benchmarks. Interesting thing is to see if Sun can keep this lead. Intel n AMD are in the process of rolling out their quad-core CPUs to market shortly. Also running a low frequency CPU, it would be interesting to see single thread performance on T2.
Sun has to really push this chip so as to pursue customers to adopt this Sparc chip instead of their usual x86 setups.
Sun is planning to introduce the next processor named Rock in next year. It would be an excitement to see what improvements does Sun bring into the new processor over T2. Sun also claims Solaris has been successfully run on T2. Using Solaris along with ZFS on T2 would be a killer combination as of now. Eagerly waiting for the first official Sun launch of a storage box based on T2.
P.S. A new MIT startup has announced its new chip Tilera, a 64 core processor with features same as US T2, likewise, on chip DIMM, gbps NICs, PCIe lanes etc. It provides a mesh of cores, which serves as an alternative for high speed bus interconnect. The clock cycles are within the range 600MHz - 900MHz. It usually takes one cycle to move data from one core to another. Would be nice to see a comparision benchmark of Tilera against US T2.
Subscribe to:
Posts (Atom)