Infinite Volume SE 技术演示文稿.ppt

* Files are distributed in a round-robin fashion to the data constituents based on the capacity threshold (preference is given to data constituents with the most available space). Files do not span data constituents; each file gets written completely in one data constituent only, and doesn’t get striped. When a write request comes in, the namespace constituent is updated with an empty file handle and the data file is written on a data constituent based on the capacity threshold. Then the data file location is updated on the namespace constituent and acknowledged back to the client. When a write request comes in, it creates an empty file handle in the namespace constituent and the file is written to a data constituent. 2nd Namespace constituent is updated with the pointer redirector to that data file location. 3rd Files are distributed in a round-robin fashion to the data constituents. Files do not span data constituents. * The read process for a data file is explained in the slide animation. * Subsequent reads to the same node (from any client connected to the LIF on the node) for the same file do not have to go to the namespace constituent to find the file location if it is saved in main memory on the requesting node. * * * * * * Infinite Volume compression and dedupe are managed and initiated at the Infinite Volume level. Under the cover that sends requests to all data constituents. Each node can run only eight compression/dedupe processes at once; additional requests will be placed in the queue. * Infinite Volume Snapshot copies are coordinated snapshots that involve fencing and snapshotting each constituent. When a snapshot for the Infinite Volume is taken, it’s a 3 step process: sends the requests to all the constituents in all the nodes to start the snapshot process, fences I/O to the Infinite Volume commits the Snapshot copies and updates the RDB tables. Snapshot copies can’t be scheduled more frequently than once per hour. * * * Infinite Volume su