Zbr's days.

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

Tue, 12 Feb 2008

POHMELFS got inode number resync logic.

It happens when inode in question is being under writeback - protocol implements quite simple ping-pong message passing, so result looks like this: 

/mnt/tmp$ echo qweqweqwe > qwe
/mnt/tmp$ ls -lai ./
total 8
    557057 drwxrwxrwt  2 root root  4096 2008-02-12 19:58 .
         2 drwxr-xr-x 22 root root  4096 2008-02-12 19:58 ..
3322992632 -rw-r--r--  0 zbr  users   10 2008-02-12 20:32 qwe
/mnt/tmp$ sync
/mnt/tmp$ ls -lai ./
total 8
   557057 drwxrwxrwt  2 root root  4096 2008-02-12 19:58 .
        2 drwxr-xr-x 22 root root  4096 2008-02-12 19:58 ..
   557065 -rw-r--r--  0 zbr  users   10 2008-02-12 20:32 qwe
But overall it does not work, since writeback can happen for any inode inside the whole not-synced tree, so trying to sync inode number for some obscure object, which sits in the directory server never saw before, is quite problematic - the whole tree has to be traversed from the inode under writeback up to the one which is known for the server host.
Although this is not a very complex task, but there is a question about what to sync. Should the whole directory content be synced, or just single inode, if the former, than should we force writeback for other objects in the directory under resync... I think the simplest case is to force only higher layer object creations, not syncing theirs content (like other objects in the directory), but directory itself should be marked as dirty, so that access from different clients forced appropriate resynchronization.

/devel/fs :: Link / Comments ()