more notes from the board

Multivolume disks?
– uid object migration in distributed environment
– have a distributed volume (e.g. lab scenario, all lab machines have same ‘volume’ mounted and sync of primary machine)

Snapshots for all versions?
– each version would require > 1 block
i.e. 10 mods of 10 bytes to 1 block would require >= 10 extra blocks
hmm… has to be better way in this scenario….

B+Tree of unique ids (seperate from walnut object IDs).

reading all about how to store stuff for reading

Otherwise titled: A day of reading about Filesystems.

I’m managing to continually find stuff I haven’t already read. I think this is a good thing. I’m clearly now going to have to do some more research into how RDMBS do things.

The idea of Snapshots sound interesting, and may prove an interesting way to help avoid having to do journalling. I’ve been thinking that journalling could be a real issue if we allow large transations, so maybe a snapshot like idea could be good. Although, this could limit the number of transactions we work on concurrently if it’s implemented the WAFL way.

So looking at how RDBMS do concurrent transactions would be useful. I guess we do have the advantage of having PostgreSQL and MySQL code to peer at but I do hope there are some nice papers out there to read :)

I’ve collected a large array of useful papers to read. I’m going to try and wade through them sometime soon, but will have to do more coursework soon.

I’m thinking tomorrow might contain a bit of coursework – need to do more POVRAY/OpenGL stuff as well as study more of the Pattern Recognition stuff. Oh, and look at the Info Security assignment & exercise for this week.

project overview doc

I’m trying to write up what has been discussed regarding my hons project.

Got a meeting penciled in for monday morning.

Should be good.

But I have to get all these ideas that have been in my head down on paper, and all the reasoning behind them.

Finally got LaTeX on my laptop. Not from DarwinPorts though :( Got it from some i-installer program that I guy did. It works, I’m happy.

transactions

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, 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).

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).

This could also be nice performance wise as we only have to lock one of these when doing operations on the log.

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.