Fwd: [Gluster-devel] glusterfs_1.4.0qa19: small issues

[Brent A Nelson]

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
>> 
>