I neglected to mention that I had not set stat-prefetch to "off" on the
newly created volume.
That's done, and output is as expected.
On 07/29/2013 05:16 PM, Nicholas Majeran wrote:
Thanks Kaushal.
A little more information:
I was never able to update that setting, so I deleted the gluster
volume, updated to the latest CentOS 6.4 kernel
(2.6.32-358.14.1.el6.x86_64), and reformatted the underlying XFS file
system.
After that, I ran a few more tests, and noticed a caching issue
whereby if I ran an "ls -l" I would sometimes see a + attached to the
dir/file in question, and sometimes I would not. See below.
[root@fs-copo05 tmp]# ls -l
total 0
drwxrwxr-x+ 2 root root 40 Jul 29 16:43 1
[root@fs-copo05 tmp]# ls -l
total 0
drwxrwxr-x 2 root root 40 Jul 29 16:43 1
[root@fs-copo05 tmp]# ls -l
total 0
drwxrwxr-x 2 root root 40 Jul 29 16:43 1
[root@fs-copo05 tmp]# ls -l
total 0
drwxrwxr-x 2 root root 40 Jul 29 16:43 1
[root@fs-copo05 tmp]# ls -l
total 0
drwxrwxr-x 2 root root 40 Jul 29 16:43 1
[root@fs-copo05 tmp]# ls -l
total 0
drwxrwxr-x+ 2 root root 40 Jul 29 16:43 1
After that, I set performance.cache-refresh-timeout to 0, and now I
see the '+' next to the direntry each time I run 'ls -l' and getfacl.
Two things:
* Is the above behavior expected?
* What are the performance implications of setting
performance.cache-refresh-timeout to 0?
Thanks.
On 07/24/2013 10:26 PM, Kaushal M wrote:
A client which mounts a volume has N connections with the N bricks and
1 connection to glusterd. The connection to glusterd is used to get
the volfiles and the ports of the bricks. For an already mounted
client this connection will still exist even if the volume was
stopped. Glusterd checks these connections when trying to set any
option. This is done to prevent older clients which don't support the
newer features from getting a newer volfile. If this isn't done, the
client will fetch the new volfile, try to understand it and fail, and
continue using the older volfile.
We could enhance this by telling exactly which clients are causing the
issue. I'll file a RFE for this.
But, that said stat-prefetch was a part of earlier releases as well,
and it was being disabled so the 'volume set' command should have gone
through. I'll check this out and reply here.
Thanks,
Kaushal
On Thu, Jul 25, 2013 at 2:44 AM, Nicholas Majeran
<nmaje...@suntradingllc.com> wrote:
That would make sense, but when I had the volume stopped, nothing
should
have been connected to that volume, correct? The volume set
operation still
failed with the volume stopped.
On 07/24/2013 03:49 PM, Joseph Landman wrote:
It says the clients don't support the ops. Is it possible to
disconnect them one at a time until the command works? Might not be
possible but it probably would tell you which client was problematic.
Also these are native client as per the subject, right?
Sent from my iPad
On Jul 24, 2013, at 2:52 PM, Nicholas Majeran
<nmaje...@suntradingllc.com> wrote:
Even with the volume stopped, I was unable to unset stat-prefetch.
Anything else I should look at?
On 07/23/2013 02:55 PM, Nicholas Majeran wrote:
FWIW, I tried to disable the parameter on a stopped volume, which
was
successful. I then started the volume and I could get/set the ACLs
normally.
I'm going to try the same procedure on the gv0 volume that threw the
error previously.
Thanks.
On 07/23/2013 02:29 PM, Nicholas Majeran wrote:
When I tried to disable that parameter, I receive the following:
gluster> volume set gv0 stat-prefetch off
volume set: failed: One or more connected clients cannot support
the
feature being set. These clients need to be upgraded or
disconnected before
running this command again
AFAICT, all the nodes are at the same version, but I did this
this in
the logs I after I ran the command:
[2013-07-23 19:26:02.673304] E
[glusterd-op-sm.c:370:glusterd_check_client_op_version_support]
0-management: One or more clients don't support the required
op-version
[2013-07-23 19:26:02.673325] E
[glusterd-syncop.c:767:gd_stage_op_phase] 0-management: Staging
of operation
'Volume Set' failed on localhost : One or more connected clients
cannot
support the feature being set. These clients need to be upgraded or
disconnected before running this command again
[2013-07-23 19:26:03.590547] E [socket.c:2788:socket_connect]
0-management: connection attempt failed (Connection refused)
[2013-07-23 19:26:06.591224] E [socket.c:2788:socket_connect]
0-management: connection attempt failed (Connection refused)
[2013-07-23 19:26:09.591912] E [socket.c:2788:socket_connect]
0-management: connection attempt failed (Connection refused)
[2013-07-23 19:26:12.592601] E [socket.c:2788:socket_connect]
0-management: connection attempt failed (Connection refused)
[2013-07-23 19:26:15.593282] E [socket.c:2788:socket_connect]
0-management: connection attempt failed (Connection refused)
[2013-07-23 19:26:18.593946] E [socket.c:2788:socket_connect]
0-management: connection attempt failed (Connection refused)
On 07/23/2013 01:45 PM, Vijay Bellur wrote:
On 07/23/2013 09:28 PM, Nicholas Majeran wrote:
A little more detail... on files, I still can't get this to
work, but
when I run ls and {get,set}facl on . it seems to work:
[root@s1 tmp]# pwd
/mnt/glusterfs/tmp
[root@s1 tmp]# ls -ld .
drwxrwxr-x+ 4 nmajeran root 4422 Jul 22 15:29 .
[root@suncosmbgw1 tmp]# ls -ld ../tmp
drwxrwxr-x 4 nmajeran root 4422 Jul 22 15:29 ../tmp
[root@s1 tmp]# getfacl .
# file: .
# owner: nmajeran
# group: root
user::rwx
user:root:rwx
user:user1:rwx
group::r-x
group:g1:rwx
group:g2:r-x
group:g3:r-x
mask::rwx
other::r-x
[root@s1 tmp]# getfacl ../tmp
# file: ../tmp
# owner: nmajeran
# group: root
user::rwx
group::rwx
other::r-x
Does disabling stat-prefetch address the problem permanently?
You can
disable stat-prefetch via:
gluster volume set <volname> stat-prefetch off
-Vijay
_______________________________________________
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users
--
Nick Majeran
Sun Trading LLC
312-229-9608
_______________________________________________
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users
--
Nick Majeran
Sun Trading LLC
312-229-9608
_______________________________________________
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users
_______________________________________________
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users
--
Nick Majeran
Sun Trading LLC
312-229-9608
_______________________________________________
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users
