[Gluster-devel] [bug?][read-ahead] when cache is invalid, should destroy all cache in the same inode_t?

LI Daobing lidaobing at kingsoft.net
Wed Dec 19 06:10:27 UTC 2007


Hi,

maybe I am overlook on this problem, :)

On Dec 19, 2007 1:47 PM, Anand Avati <avati at zresearch.com> 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





More information about the Gluster-devel mailing list