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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux