I’m thinking that I can easily do multiple FS ops in one transaction with some careful structuring of the journal.<\/p>\n
The only problem with this is the old problem of journal size. Unlike a normal journaled FS, with user transactions, we may be dealing with a lot more data in many transactions and a static log size may be a bad thing (and severely limit the size of transactions that are possible).<\/p>\n
I’m thinking that having an expandable log (perhaps a linked-list kind of approach) could be quite useful. In memory, we’ll probably need another data structure to have things remotely efficient (esp if we want to know where to write additional log entries).<\/p>\n
This could also be nice performance wise as we only have to lock one of these when doing operations on the log.<\/p>\n
I’ve also been thinking about weird things like delayed index updates. That is, you update a file (or attributes) and it doesn’t update the index pointing to it on disk until it is conveinient for it to do so.<\/p>\n","protected":false},"excerpt":{"rendered":"
I’m thinking that I can easily do multiple FS ops in one transaction with some careful structuring of the journal. The only problem with this is the old problem of journal size. Unlike a normal journaled FS, with user transactions, … Continue reading