Hi, I'm interested in knowing more about the internal log journals GPFS uses to track file system activity from client nodes.
My understanding is that when a file is opened for writing on a node, that (first) node becomes the 'metanode' for the file and is responsible for making updates to the file's metadata. Does the matanode also have responsibility for tracking changes made by other nodes that open the same file in its own journal, or are these recorded in each nodes own journal? I'm also interested in what happens when a node fails and its logs are replayed by the FS manager... what happens if that node is acting as metanode for a lot of open files which are also open elsewhere for writing on other nodes? If in the above scenario the metanode is handling metadata updates and tracking other changes in its journal, do all other nodes need to wait for the metanode to be ejected and have its journal replayed before they can continue? What is the process for selecting a successor metanode for the open files? Another related question I have is about initial sizing when creating a file system. Presumably the estimate for the total number of nodes mounting the file system affects the structure / allocation of internal journal logs? How are these arranged and is there any advice to overestimate this number if you intend to add more nodes at a future time? In the same vein, do multicluster nodes that join another remote stripegroup get allocated internal journal space as if they were new nodes in the remote cluster? Are these nodes allowed to be metanodes for files in a remote cluster? What happens when these nodes fail? Any insights greatly appreciated! Cheers, Luke. -- Luke Raimbach IT Manager Oxford e-Research Centre 7 Keble Road, Oxford, OX1 3QG +44(0)1865 610639 _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at gpfsug.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
