How filesystem transactions work 2016/03/17, 15:48:21
I'm doing some work on the system documentation. For this I made a diagram that shows how filesystem transactions are working in Ghost. The following explanation applies to the read operation when a driver task is involved. Filesystem drivers in Ghost run in user space, therefore they run in their own task.
- a filesystem node has a delegate that has the implementation of the underlying filesystem operations (read, write, open etc.)
- a filesystem node is mapped to a process via a file descriptor
- the transaction store holds a status for each running transaction
- a waiter object is used to store waiting information for one task and decide whether a task shall keep sleeping during scheduling
- requesting task creates the request structure and performs the read system call
- the system call handler looks up the filesystem node for the given file descriptor
- the system call handler creates a transaction handler that is responsible for keeping track of the transaction status and performing the requested operations
- the transaction handler tells the delegate to start a transaction
- the requesting task is put to sleep and a filesystem transaction waiter object is appended
- the delegate starts a new transaction in the transaction store (retrieving the transaction id)
- the delegate asks the driver task to perform the read operation
- the delegate sets the transaction status to "waiting"
- the driver task now does anything that is necessary to perform the read operation, like querying the hard disk etc.
- the driver task sets the status of the transaction to "finished" once its done (using the fs-set-transaction-status-syscall)
- the waiter object is continously checking the transaction store whether the transaction has finished. while the driver performs the transaction, the waiter tells the scheduler to keep waiting
- once the transaction status is "finished" the waiter object tells the transaction handler to finish the operation
- the transaction handler finishes the transaction by writing the result data into the requesting tasks request structure
- the waiter is removed from the requesting task
The request object in the requesting task now contains the result of the operation.