As of today, Gluster's inode tables are associated with a translator instance. So when a graph switch happens (some volume set, add-brick type of operations), there will be another inode table created, and upon activity, entry by entry, inode data would be migrated.
This operation is very 'bug' friendly. But, but moving the inode table to global context instead of translator, we don't need to change inode table after graph switch, but just need to update the context.
As of today, Gluster's inode tables are associated with a translator instance. So when a graph switch happens (some
volume set,add-bricktype of operations), there will be another inode table created, and upon activity, entry by entry, inode data would be migrated.This operation is very 'bug' friendly. But, but moving the inode table to global context instead of translator, we don't need to change inode table after graph switch, but just need to update the context.