gluster-devel
[Top][All Lists]
Advanced

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

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


From: Brent A Nelson
Subject: Re: Fwd: [Gluster-devel] glusterfs_1.4.0qa19: small issues
Date: Wed, 25 Jun 2008 15:13:01 -0400 (EDT)

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]