Re: Error in logs from catting a deleted file?

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

 



On Thu, May 15, 2008 at 12:49 PM, Gordan Bobic <gordan@xxxxxxxxxx> wrote:

> If I do the following:
> (/home being the glusterfs mount point)
> node1$ echo "test" > /home/test
> node1$ cat /home/test
> test
>
> node2$ cat /home/test
> test
> node2$ rm /home/test
> node1$ cat /home/test
>
> I get the following in the error log on node1:
> 2008-05-15 20:44:30 E [fuse-bridge.c:459:fuse_entry_cbk] glusterfs-fuse:
> 80: (34) /test => -1 (2)
>

This is because, the inode cache at node1's VFS is not flushed after node2
deletes the file. Hence when you cat, it does a lookup for the file, (with
the inode cache of vfs), but it got ENOENT (file not found) error, and the
inode cache is flushed after this.


> The behaviour of the FS is correct (the file gets deleted and the delete
> propagates to both nodes).
>
> I'm using AFR with NUFA scheduler.


AFR with NUFA ? I am not sure how did you managed to get schedulers working
with AFR. Schedulers are meant for scheduling creat(), and used *only* by
cluster/unify translator as of now.



>
>
> Is this just over-paranoid logging, or is there really something going
> wrong?
>

Its a paranoid logging. We are working on reducing number of such logs.

Regards,

-- 
Amar Tumballi
Gluster/GlusterFS Hacker
[bulde on #gluster/irc.gnu.org]
http://www.zresearch.com - Commoditizing Super Storage!


[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