Zbr's days.

About :: TODO :: Blog :: RSS :: Old blog :: Projects :: GIT :: Gallery :: Notes

Tue, 05 Feb 2008

POHMELFS inode generation and cache coherency.

I think I've just designed the way to fix the problem with overlapping inodes on different clients or server and clients.

Here is short problem description: when client locally creates some object, it has to assign unique number to its inode and put it into global hash tables. With local cache and maximum performance (or when client is offline) it shold not connect to server and perform create operation at all, instead it should pick some number for inode and work with it.
Problem is that number of clients can have the same inode number for different inodes and have actually the same object but with different inode number on different client's machine.
When clients and server will have to sync its states problem rises: server does not know about inode with client's number and thus sync can not happen.

Solution is quite simple imo, which solves both cache coherency problem and inode number one.
Clients use any numbers they like: for example sequential increase from zero. When new object is created its parent is marked as dirty by client (if it is already marked as dirty by other clien, it is forced to push its changes to the server, which then will be forwarded to the new client), and client uses own inode numbering scheme. When later there is a need for resync (lile forced writeback or above case of cache coherency synchronization), client sends inode content to the server with both name and local inode number. Server then creates an object and assigns real unique inode number to it, which is then returned back to client. Client removes inode with old (local) number from hash and inserts it back with different inode number. That's all.

Simple. And allows to work with any filesystem on the server side because system uses both object name and object id (inode number) as identificators during creation time.

So far I do not see any drawbacks in this approach, but practice will show if it is correct design or not. Stay tuned.

/devel/fs :: Link / Comments ()