You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to be able to delete files. Currently calling unlink() is a NOP:
delete all index info associated with file
free storage in all superblocks (memory and spill over)
This is tricky in that with traditional parallel file systems, only one process must call unlink(). For us to match that behavior, the unlink() from a single client must send a message to the delegators, which must then reach into the superblock file structures on each client to free off storage resources. To do that, the delegator will need to lock the superblock for write access so it doesn't conflict with changes the client might be making.
The text was updated successfully, but these errors were encountered:
adammoody
changed the title
Add support unlink()
Add support for unlink()
Nov 9, 2018
An alternative design that will simplify things is to restructure things so that the server manage the storage chunks. Writes from the client would then transfer data from client to server, and the server would write data. Reads would not be changed. This will enable the server to delete a file and free its storage without needing to share locks with the client.
We need to be able to delete files. Currently calling unlink() is a NOP:
This is tricky in that with traditional parallel file systems, only one process must call unlink(). For us to match that behavior, the unlink() from a single client must send a message to the delegators, which must then reach into the superblock file structures on each client to free off storage resources. To do that, the delegator will need to lock the superblock for write access so it doesn't conflict with changes the client might be making.
The text was updated successfully, but these errors were encountered: