Hi, maybe I am overlook on this problem, :) On Dec 19, 2007 1:47 PM, Anand Avati <avati@xxxxxxxxxxxxx> wrote: > > > > > > now the cache is bind to fd_t, and when there is a write command, only > > the cache in this fd_t is mark dirty. I think this scheme has problem > > in the real world. > > > This problem exists with fd's on two client machines as well (where flushing > on inode does not help). Applications which are concerned about such fine > grained concurrent access should hold record locks and operate, during which > data is always freshly fetched. > If there are two process on two client, of course they should take care this by itself. But if only one client, glusterfs should work like a normal file system. if two process work on one client, this is a normal interprocess communication method, so It should work on any filesystem. But glusterfs does not support it. Even you can consider one process open one file twice, it bug also will happen. And many program really use this scheme, such as Gaussian(a Quantum Chemistry Program). Gaussian use files to communicate between threads. And the file is somehow large(often tens of 2G files), so they put it on a glusterfs. And It works on a ext3 partition but maybe will crash on glusterfs. What do you think? Best Regards, LI Daobing
