In most cases, when we create data structure for an open PLFS file, we allocate and set the filename and backing store information as the data structure is created (so there isn't concurrent access, as the data structure doesn't go "live" until it is fully set up).
However, if we have an open file and we rename with FUSE, then the Plfs_fd::renamefd(ppip_to) API is called. That routine is supposed to and update all the paths and backing store information to point to the new name.
As things currently stand, this operation isn't atomic --- there is no locking on the filenames and backing store info (e.g. when Container_OpenFile setPath is called). If the COF is concurrently accessed by more than one thread and a renamefd is active, the filename info can be in an inconsistent state (partially updated).
Also, some of the filenames are stored in C++ "strings" -- I'm not clear how thread safe they are (e.g. if we have concurrent rename ops running, or we have a thread trying to read a string while another rename thread is in the process of updating it). I know we had to add mutex protection for the C++ maps. Most of the time we don't modify these strings, so it isn't an issue unless we are renaming.
In most cases, when we create data structure for an open PLFS file, we allocate and set the filename and backing store information as the data structure is created (so there isn't concurrent access, as the data structure doesn't go "live" until it is fully set up).
However, if we have an open file and we rename with FUSE, then the Plfs_fd::renamefd(ppip_to) API is called. That routine is supposed to and update all the paths and backing store information to point to the new name.
As things currently stand, this operation isn't atomic --- there is no locking on the filenames and backing store info (e.g. when Container_OpenFile setPath is called). If the COF is concurrently accessed by more than one thread and a renamefd is active, the filename info can be in an inconsistent state (partially updated).
Also, some of the filenames are stored in C++ "strings" -- I'm not clear how thread safe they are (e.g. if we have concurrent rename ops running, or we have a thread trying to read a string while another rename thread is in the process of updating it). I know we had to add mutex protection for the C++ maps. Most of the time we don't modify these strings, so it isn't an issue unless we are renaming.