search for: posix_removexattr

On Fri, Jul 7, 2017 at 9:25 PM, Ankireddypalle Reddy <areddy at commvault.com> wrote: > 3.7.19 > These are the only callers for removexattr and only _posix_remove_xattr has the potential to do removexattr as posix_removexattr already makes sure that it is not gfid/volume-id. And surprise surprise _posix_remove_xattr happens only from healing code of afr/ec. And this can only happen if the source brick doesn't have gfid, which doesn't seem to match with the situation you explained. # line filename / contex...

...ireddypalle Reddy > *Cc:* Gluster Devel (gluster-devel at gluster.org); gluster-users at gluster.org > *Subject:* Re: [Gluster-devel] gfid and volume-id extended attributes lost > > > > Did anything special happen on these two bricks? It can't happen in the > I/O path: > posix_removexattr() has: > 0 if (!strcmp (GFID_XATTR_KEY, name)) > { > > > 1 gf_msg (this->name, GF_LOG_WARNING, 0, > P_MSG_XATTR_NOT_REMOVED, > 2 "Remove xattr called on gfid for file %s", > real_path); > 3...

...r-devel at gluster.org<mailto:gluster-devel at gluster.org>); gluster-users at gluster.org<mailto:gluster-users at gluster.org> Subject: Re: [Gluster-devel] gfid and volume-id extended attributes lost Did anything special happen on these two bricks? It can't happen in the I/O path: posix_removexattr() has: 0 if (!strcmp (GFID_XATTR_KEY, name)) { 1 gf_msg (this->name, GF_LOG_WARNING, 0, P_MSG_XATTR_NOT_REMOVED, 2 "Remove xattr called on gfid for file %s", real_path); 3 op_ret = -1; 4 goto out;...

...el] gfid and volume-id extended attributes lost On Fri, Jul 7, 2017 at 9:25 PM, Ankireddypalle Reddy <areddy at commvault.com<mailto:areddy at commvault.com>> wrote: 3.7.19 These are the only callers for removexattr and only _posix_remove_xattr has the potential to do removexattr as posix_removexattr already makes sure that it is not gfid/volume-id. And surprise surprise _posix_remove_xattr happens only from healing code of afr/ec. And this can only happen if the source brick doesn't have gfid, which doesn't seem to match with the situation you explained. # line filename / contex...

...utes lost > > > > > > > > On Fri, Jul 7, 2017 at 9:25 PM, Ankireddypalle Reddy <areddy at commvault.com> > wrote: > > 3.7.19 > > > > These are the only callers for removexattr and only _posix_remove_xattr > has the potential to do removexattr as posix_removexattr already makes sure > that it is not gfid/volume-id. And surprise surprise _posix_remove_xattr > happens only from healing code of afr/ec. And this can only happen if the > source brick doesn't have gfid, which doesn't seem to match with the > situation you explained. > >...

Did anything special happen on these two bricks? It can't happen in the I/O path: posix_removexattr() has: 0 if (!strcmp (GFID_XATTR_KEY, name)) { 1 gf_msg (this->name, GF_LOG_WARNING, 0, P_MSG_XATTR_NOT_REMOVED, 2 "Remove xattr called on gfid for file %s", real_path); 3 op_ret = -1; 4 goto out...

...gt;> >> On Fri, Jul 7, 2017 at 9:25 PM, Ankireddypalle Reddy < >> areddy at commvault.com> wrote: >> >> 3.7.19 >> >> >> >> These are the only callers for removexattr and only _posix_remove_xattr >> has the potential to do removexattr as posix_removexattr already makes sure >> that it is not gfid/volume-id. And surprise surprise _posix_remove_xattr >> happens only from healing code of afr/ec. And this can only happen if the >> source brick doesn't have gfid, which doesn't seem to match with the >> situation you explai...

...2017 at 9:25 PM, Ankireddypalle Reddy < >>> areddy at commvault.com> wrote: >>> >>> 3.7.19 >>> >>> >>> >>> These are the only callers for removexattr and only _posix_remove_xattr >>> has the potential to do removexattr as posix_removexattr already makes sure >>> that it is not gfid/volume-id. And surprise surprise _posix_remove_xattr >>> happens only from healing code of afr/ec. And this can only happen if the >>> source brick doesn't have gfid, which doesn't seem to match with the >>> situ...

...Reddy < >>>> areddy at commvault.com> wrote: >>>> >>>> 3.7.19 >>>> >>>> >>>> >>>> These are the only callers for removexattr and only _posix_remove_xattr >>>> has the potential to do removexattr as posix_removexattr already makes sure >>>> that it is not gfid/volume-id. And surprise surprise _posix_remove_xattr >>>> happens only from healing code of afr/ec. And this can only happen if the >>>> source brick doesn't have gfid, which doesn't seem to match with the >&...

...el] gfid and volume-id extended attributes lost On Fri, Jul 7, 2017 at 9:25 PM, Ankireddypalle Reddy <areddy at commvault.com<mailto:areddy at commvault.com>> wrote: 3.7.19 These are the only callers for removexattr and only _posix_remove_xattr has the potential to do removexattr as posix_removexattr already makes sure that it is not gfid/volume-id. And surprise surprise _posix_remove_xattr happens only from healing code of afr/ec. And this can only happen if the source brick doesn't have gfid, which doesn't seem to match with the situation you explained. # line filename / contex...

...utes lost > > > > > > > > On Fri, Jul 7, 2017 at 9:25 PM, Ankireddypalle Reddy <areddy at commvault.com> > wrote: > > 3.7.19 > > > > These are the only callers for removexattr and only _posix_remove_xattr > has the potential to do removexattr as posix_removexattr already makes sure > that it is not gfid/volume-id. And surprise surprise _posix_remove_xattr > happens only from healing code of afr/ec. And this can only happen if the > source brick doesn't have gfid, which doesn't seem to match with the > situation you explained. > >...

...ent: Friday, July 07, 2017 11:46 AM To: Ankireddypalle Reddy Cc: Gluster Devel (gluster-devel at gluster.org); gluster-users at gluster.org Subject: Re: [Gluster-devel] gfid and volume-id extended attributes lost Did anything special happen on these two bricks? It can't happen in the I/O path: posix_removexattr() has: 0 if (!strcmp (GFID_XATTR_KEY, name)) { 1 gf_msg (this->name, GF_LOG_WARNING, 0, P_MSG_XATTR_NOT_REMOVED, 2 "Remove xattr called on gfid for file %s", real_path); 3 op_ret = -1; 4 goto out;...

Hi, We faced an issue in the production today. We had to stop the volume and reboot all the servers in the cluster. Once the servers rebooted starting of the volume failed because the following extended attributes were not present on all the bricks on 2 servers. 1) trusted.gfid 2) trusted.glusterfs.volume-id We had to manually set these extended attributes to start the volume.