Just a quick note that this doesn't seem to be any sort of corruption
issue. I completely emptied all my shares (even removing lost+found) and
my namespace and rsynced the corresponding AFR shares and namespace. The
only thing different between the AFRs would be ctimes.
I restarted everything, and did:
ls -al /beast
ls: /beast: File exists
ls: /beast/.: File exists
total 8
drwxr-xr-x 2 root root 4096 2007-07-17 09:27 .
drwxr-xr-x 27 root root 4096 2007-07-02 10:18 ..
I also tried disabling readahead and writebehind (my only performance
translators). It didn't help. Changing the unify from alu to rr also
didn't help.
I then tried "glusterfs -f /etc/glusterfs/beast -n mirror0 /beast" to
mount a single AFR, no unify. It STILL produces the same messages.
I then tried "glusterfs -f /etc/glusterfs/beast -n share0-0 /beast" to
mount a simple, single share used as half of an AFR. Same issue.
I then stripped down a server to serve out one single storage/posix share,
with no posix locks (I wasn't using any other translators on the server
side, apart from protocol/server, of course). I mounted that share as in
the previous attempt. No difference!
So, this issue occurs even with just protocol/client, protocol/server, and
storage/posix in use. As barebones as you can get. Almost.
One more try. No glusterfsd, and glusterfs accesses a single
storage/posix directly:
ls -al /beast
ls: /beast: File exists
ls: /beast/.: File exists
total 8
drwxr-xr-x 2 root root 4096 2007-07-17 09:27 .
drwxr-xr-x 27 root root 4096 2007-07-02 10:18 ..
No difference, even with just glusterfs directly accessing a single, local
storage/posix, with no other translators. Spec is simply:
volume share0
type storage/posix # POSIX FS translator
option directory /share0 # Export this directory
end-volume
Ubuntu Feisty, Fuse 2.6.3.
Any ideas?
Thanks,
Brent
On Sat, 14 Jul 2007, Brent A Nelson wrote:
> It's the same spec I was using previously (AFRed namespace cache,
unified
> AFRs spread across four servers, posix-locks, readahead, and
writebehind).
> It's not just the top-level directory; it's everywhere.
>
> Thanks,
>
> Brent
>
> On Sat, 14 Jul 2007, Anand Avati wrote:
>
>> Brent,
>> this is strange, we are having patch-313 work pretty smooth so far. are
>> there any changes in your spec? is this behaviour seen only in this
>> particular directory or 'anywhere' in general? please attach your spec
so
>> that we can try to reproduce it in our labs.
>>
>> thanks,
>> avati
>>
>> 2007/7/14, Brent A Nelson <address@hidden>:
>>>
>>> Updating to the latest TLA patch, I got odd issues just with "ls":
>>>
>>> Example:
>>>
>>> ls -al /beast/
>>> ls: /beast/: No such file or directory
>>> ls: /beast/.: No such file or directory
>>> ls: /beast/lost+found: No such file or directory
>>> ls: /beast/usr0: No such file or directory
>>> ls: /beast/usr: No such file or directory
>>> total 32
>>> drwxr-xr-x 5 root root 4096 2007-07-13 16:18 .
>>> drwxr-xr-x 27 root root 4096 2007-06-25 18:34 ..
>>> drwx------ 2 root root 16384 2007-06-25 17:08 lost+found
>>> drwxr-xr-x 10 root root 4096 2007-06-18 13:31 usr
>>> drwxr-xr-x 10 root root 4096 2007-06-18 13:31 usr0
>>>
>>> I have one machine that is no longer returning from an "ls". I get
other
>>> messages sometimes, not just "No such file or directory", but also
"Bad
>>> file descriptor" or even "File exists". These extraneous messages are
>>> also occurring when copying from the GlusterFS to the GlusterFS. The
>>> files and directories mentioned do, in fact, exist, no matter what the
>>> extraneous error message says.
>>>
>>> Is there a known issue with the current patchset?
>>>
>>> Thanks,
>>>
>>> Brent
>>>
>>>
>>> _______________________________________________
>>> Gluster-devel mailing list
>>> address@hidden
>>> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>>>
>>
>>
>>
>> --
>> Anand V. Avati
>>
>
strace.cp-a