My world of Unix and Storage

With flare 30, pool is the new feature.and mixed pool is something totally new. You can combine multiple disk type in a common raid configuration and put it inside the pool. Enable auto-tiering and you are promised for a good performance by moving data across different tiers, the catch (its not real time, unlike VMAX). If you have totally unpredicted I/O then by the time it is decided to move the data above or below the tiers the I/O profile gets completely changed. In the next version of he flare, you can have disks in different raid type inside a single pool. What goes inside the pool, how the data is striped or written is something internal to EMC. The very idea is to give customers a very comfortable way of handling the storage leaving the pain to EMC. However, things are always not green as it looks. This works well when you have predictable I/O, you know what is going inside and when. What if the dynamics changes every now and then and you do not have control over the I/O ...

Version 3 maintains persistent locks. When a file system is unshared and shared back the locks are not destroyed so the state remains the same as if nothing has changed. Version 4 removes any state once the file system is unshared. All the state information is removed and any attempt to access the file again once shared back results in I/O error. The state does not change if it was unshared for some share option changes. Pseudo file system name space is maintained in version 4. In version 3 clients must request for individual mount of the entire exported share. Version 4 client gets a seamless view of all the exported file system. Path traversal was not allowed in version 3. Version 4 supports volatile file handles apart from persistent file handle. Server generates a unique file handle to every file. The file handle will change if the file is deleted and replaced by another file however will remain the same if server reboots or file was renamed. In oracle version 4 client con...