About TODO Blog RSS Old blog Projects Gallery Notes

Wed, 06 Feb 2008

Climbing evening.

That was my second training this year - not a very huge progress as you can see, so this training was hard. There is fair number of new traces, most of them were quite simple, so I decided to run several in one go without the rest in-between. Probably that was not that good decision, since after 7 or so of them completed after two starts I was very tired and was not able to climb good over more complex traces. So that will be postponed for the next training.
I bought myself new climbing shoes, which are a bit large - usually I wear 3 sizes smaller climbing shoes, this time difference is only two sizes, but it is my favourite shoes, so I expect very good climbing.

Anyway, tired very noticebly and that's great!

/life :: Link / Comments (0)

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 (0)