Bug 1414758
| Summary: | quota: limit-usage command failed with error " Failed to start aux mount" | |||
|---|---|---|---|---|
| Product: | [Red Hat Storage] Red Hat Gluster Storage | Reporter: | Anil Shah <ashah> | |
| Component: | quota | Assignee: | Sanoj Unnikrishnan <sunnikri> | |
| Status: | CLOSED ERRATA | QA Contact: | Anil Shah <ashah> | |
| Severity: | high | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | rhgs-3.2 | CC: | amukherj, asrivast, rhinduja, rhs-bugs, storage-qa-internal, sunnikri | |
| Target Milestone: | --- | |||
| Target Release: | RHGS 3.3.0 | |||
| Hardware: | x86_64 | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | glusterfs-3.8.4-25 | Doc Type: | Bug Fix | |
| Doc Text: |
Quota list and limit commands now create and destroy aux mounts each time they are run to reduce the risk of encountering stale mount points. Additionally, a separate mount point is now used for list and limit commands in order to avoid issues when these commands are run in parallel.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1433906 (view as bug list) | Environment: | ||
| Last Closed: | 2017-09-21 04:30:55 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | 1433906 | |||
| Bug Blocks: | 1417147 | |||
|
Description
Anil Shah
2017-01-19 11:36:52 UTC
From the logs, The aux mount location /var/run/gluster/testvol0/ has not been cleanly unmounted from the previous run. We can also infer that no process was mounted on aux-mount path. The aux mount is created on the first limit/remove_limit/list command on the volume and it remains until volume is stopped / deleted / quota is disabled on the volume (where we do a lazy unmount). A lazy unmount would have instantaneously removed the path to the mount point, since the path still exists we can rule out a lazy unmount on the path. Hence it looks like the process (aux)mounted was uncleanly terminated and hence we did not do a lazy unmount. Need to see if the cleanup script in di-staf can be doing this. create volume, start, mount, enable quota [root@localhost mnt]# mount | grep gluster localhost:v1 on /run/gluster/v1 type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072) 10.70.1.217:v1 on /mnt type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072) [root@localhost mnt]# kill -9 9317 >> notice the stale mout on /run/gluster/v1 [root@localhost mnt]# mount | grep gluster localhost:v1 on /run/gluster/v1 type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072) 10.70.1.217:v1 on /mnt type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072) >> [root@localhost mnt]# ls /run/gluster/v1 ls: cannot access '/run/gluster/v1': Transport endpoint is not connected While the scenario leading to the stale mount hasn't been RCA'd, One plausible approach to avoid the issue would be to have all commands(limit/remove_limit/list) umount the aux path before it finishes. The reason why this was not done in the first place is to avoid mount on subsequent commands, this is a tiny performance improvement we could do away with. Another risk with keeping the aux mount around too long is that if the user inadvertently did an 'rm' over the /var/run. It could delete all the persistent filesystem data. while clearing /var/run is not expected. It shouldn't have such side effect (being a temporary directory). upstream patch : https://review.gluster.org/16938 downstream patch : https://code.engineering.redhat.com/gerrit/#/c/105515/ Observer aux mount is not created at path /var/run/gluster/ Explicitly mounted other volume on aux mount path , quota list command gives the correct output. Bug verified on build glusterfs-3.8.4-27.el7rhgs.x86_64 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2774 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2774 |