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

Wed, 06 Feb 2008

Continuing POHMELFS client side caching design (offline working capabilities).

As I wrote previously, accepted design of the local cache allows not only to fix problem cases with inode generation numbers, but also provides a very interesting feature with offline working.

Let's suppose client was moved offline or just does not yet synced its cache with the server. It can work without any problem and later when it connects back to server system will resync its data with server one. For all files, which are different on client and server, client will have an own version, but with different name (like orig_name-$date_of_sync), so that user could run diff or anything else and merge changes properly.
Number of usage cases for this excellent imho functionality is extremely large...
There is a problem though, since client's memory is limited, and eventually writeback will start pushing data to server, so for such cases client has to have ability to cache not only to mem, but to disk too. That is future extension though.

An anounymous reader dropped me a note, that such behaviour of locally cached files, when its inode number will change after resync with server, will be frowned upon by some RSBAC systems.
I believe that inode-only based approach is broken because of heavy problems with filesystems, when file can be changed by different clients. There is a possibility to remove file and then create new one, and it will have the same inode number as just removed one, so withough knowing name of the file system will be screwed. And how does this system work with hardlinks, which have the same inode number as target object, but different names?

/devel/fs :: Link / Comments ()