Re: Strange inconsistencies (No such file or directory)

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

 



Brian Taber wrote:
Ok, I tried the debug once before, must have missed it.  I did see dome
errors on the client side, but not the server side.  Here is the log
excert:

2007-10-22 00:19:07 D [inode.c:351:__active_inode] fuse/inode: activating
inode(16750137), lru=1/1024
2007-10-22 00:19:07 D [fuse-bridge.c:423:fuse_lookup] glusterfs-fuse:
LOOKUP 16750137/1193026747.V19Iffa3a9M917884.anubis.mydomain.com
(/mydomain.com/webmaster/new/1193026747.V19Iffa3a9M917884.anubis.mydomain.com)
2007-10-22 00:19:07 D [fuse-bridge.c:378:fuse_entry_cbk] glusterfs-fuse:
ERR => -1 (2)
2007-10-22 00:19:07 D [inode.c:308:__destroy_inode] fuse/inode: destroy
inode(0) [@0x7bbe4a0]
2007-10-22 00:19:07 D [inode.c:381:__passive_inode] fuse/inode:
passivating inode(16750137), lru=2/1024
2007-10-22 00:19:07 D [inode.c:351:__active_inode] fuse/inode: activating
inode(16753577), lru=1/1024
2007-10-22 00:19:07 D [inode.c:351:__active_inode] fuse/inode: activating
inode(16750137), lru=0/1024
2007-10-22 00:19:07 D [fuse-bridge.c:1052:fuse_link] glusterfs-fuse: LINK
/mydomain.com/webmaster/tmp/1193026747.P24588.anubis.mydomain.com
/mydomain.com/webmaster/new/1193026747.V19Iffa3a9M917884.anubis.mydomain.com
2007-10-22 00:19:07 D [fuse-bridge.c:346:fuse_entry_cbk] glusterfs-fuse:
ENTRY => 16753577
2007-10-22 00:19:07 D [inode.c:381:__passive_inode] fuse/inode:
passivating inode(16753577), lru=1/1024
2007-10-22 00:19:07 D [fuse-bridge.c:917:fuse_unlink] glusterfs-fuse:
UNLINK 16750136/1193026747.P24588.anubis.mydomain.com

The client and server run fine without crashing, so I really couldn't
backtrace it (or could I?)

I tried to find the tla release you mentioned, I am not sure which one to
use, do you have a direct link I could use?

I don't see any errors there (the "D" after the time stamp denotes it's a debug level message. It looks like a normal maildir operation to me.

Question: In the order of operation you described for the original problem, where server 1 is running postfix and can't access the message after a while, what exactly is failing, what's causing the error? I don't see how it could be postfix, as postfix's responsibility ends at the delivery of the message into the maildir store. Is there a IMAP client running on this server? I assume there's an IMAP client running on server 2, the webmail server.

It's normal in maildir folders for messages to be moved around from tmp/ to cur/ and new/, and in this case it's using hard links for atomic operations (as the LINK entry in fuse shows). I can only think of 2 things that might be happening to cause this (but that's just me), either glusterfs has a problem with hard links (which I'm not seeing on my end, but I doubt I'm replicating what your IMAP client does exactly), or one of the servers still thinks it will see a file in the new/ dir of a maildir root after it's been moved to cur/ (that is, it's been viewed), which could either be an application problem or a glusterfs caching issue (if any of the translators you use can cache directory data, which I'm fuzzy on).

--

-Kevan Benson
-A-1 Networks




[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