Thanks Brent,
These tests were extremely helpful for us in making 1.4.x release stable.
We will have fix for all these bugs/observation. I will write back with the
update soon.
Regards,
Amar
2008/6/25 Brent A Nelson <brent@xxxxxxxxxxxx>:
> Additionally, I think there is a slow server-side memory leak in the new
> branch, with repeated rsync/rm cycles (large dd testing still works like a
> champ, though, with no increase in memory consumption). About half of my
> server processes are currently ~400MB (the other half never grew, though,
> probably inidicating their different role in the AFRs).
>
> When I tried 1.3.9, it did not seem to grow; otherwise, the 1.4 branch
> seems to be consistantly better than 1.3.9. rsyncs of complex directories
> are about twice as fast at about half the client CPU usage. Also, 1.3.9
> seemed to randomly make some directories mode 777, after they were copied
> properly (self-heal oddity? could be a goof in testing, though).
>
> Let me know if you need anything else to help track down the other two
> issues, below.
>
> Thanks,
>
> Brent
>
>
> On Tue, 24 Jun 2008, Brent A Nelson wrote:
>
> I've just tested with 1.3.9. It has both problems, as well; they're not
>> unique to the 1.4 branch.
>>
>> Thanks,
>>
>> Brent
>>
>> On Tue, 24 Jun 2008, Anand Avati wrote:
>>
>>
>>>> I believe I've narrowed down the setuid issue to a glitch in hardlink
>>>> handling. It was happening in the case of /usr/bin/sudoedit apparently
>>>> because sudoedit is a hardlink to sudo. When cp -a does the hardlink,
>>>> it
>>>> wipes out the setuid bit. I'm fairly certain this is what's happening,
>>>> as I
>>>> tried the cp -a with a bin directory that had sudo removed, and
>>>> GlusterFS
>>>> happily preserved the setuid bit. Try again with sudo present, it
>>>> fails.
>>>> Try again with sudo and sudoedit not being hardlinks, and it works!
>>>>
>>>
>>>
>>> great clue! just curious if this was not observed in the previous version
>>> (1.3.x) as well?
>>>
>>>
>>> Is anyone having any luck with "cp -a"'s inability to preserve directory
>>>
>>>> permissions? In case it helps, here's an strace snippet from "cp -a blah
>>>> /beast" where blah is an empty directory, mode 755, and /beast is my
>>>> GlusterFS:
>>>>
>>>
>>>
>>> there is no chmod/fchmod call issued by cp in the strace. Again, is this
>>> observed in the new mainline and not in previous versions?
>>>
>>>
>>> stat64("/beast", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>>>
>>>> lstat64("blah", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>>>> lstat64("/beast/blah", 0xbfca01ec) = -1 ENOENT (No such file or
>>>> directory)
>>>> mkdir("/beast/blah", 0700) = 0
>>>> lstat64("/beast/blah", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
>>>> open("blah", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 3
>>>> fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>>>> fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
>>>> getdents64(3, /* 2 entries */, 4096) = 48
>>>> getdents64(3, /* 0 entries */, 4096) = 0
>>>> close(3) = 0
>>>> futimesat(AT_FDCWD, "/beast/blah", {1214261897, 0}) = 0
>>>> lchown32("/beast/blah", 0, 0) = 0
>>>> getxattr("blah", "system.posix_acl_access", 0xbfc9fe50, 132) = -1
>>>> EOPNOTSUPP (Operation not supported)
>>>> setxattr("/beast/blah", "system.posix_acl_access",
>>>>
>>>> "\x02\x00\x00\x00\x01\x00\x07\x00\xff\xff\xff\xff\x04\x00\x05\x00\xff\xff\xff\xff
>>>> \x00\x05\x00\xff\xff\xff\xff", 28, 0) = 0
>>>> removexattr("/beast/blah", "system.posix_acl_default") = 0
>>>> close(0) = 0
>>>> close(1) = 0
>>>> close(2) = 0
>>>> exit_group(0) = ?
>>>>
>>>
>>>
>>>
>>> avati
>>>
>>>
>>
>
--
Amar Tumballi
Gluster/GlusterFS Hacker
[bulde on #gluster/irc.gnu.org]
http://www.zresearch.com - Commoditizing Super Storage!
