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

[Raghavendra G]

Hi Brent,
glusterfs--mainline--3.0--patch-205 contains fix for setuid bit not being
preserved for hardlinks during cp.

regards,
On Thu, Jun 26, 2008 at 12:41 AM, Amar S. Tumballi <amar at zresearch.com>
wrote:

> 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 at phys.ufl.edu>:
>
> > 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!
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>



-- 
Raghavendra G

A centipede was happy quite, until a toad in fun,
Said, "Prey, which leg comes after which?",
This raised his doubts to such a pitch,
He fell flat into the ditch,
Not knowing how to run.
-Anonymous