[Bugs] [Bug 1330032] rm -rf to a dir gives directory not empty(ENOTEMPTY) error
bugzilla at redhat.com
bugzilla at redhat.com
Mon Apr 25 10:31:34 UTC 2016
https://bugzilla.redhat.com/show_bug.cgi?id=1330032
Nithya Balachandran <nbalacha at redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Comment #0 is|1 |0
private| |
Status|NEW |ASSIGNED
Assignee|bugs at gluster.org |nbalacha at redhat.com
--- Comment #1 from Nithya Balachandran <nbalacha at redhat.com> ---
Steps to reproduce the issue:
1. Create a 2x2 dist-rep volume.
2. Set cluster.quorum-type to auto.
3. NFS mount the volume
4. mkdir -p dir1/dir2/dir3/dir4
5. Kill the first brick process for the non-hashed subvol for dir4
6. Try to delete dir4 : rmdir dir1/dir2/dir3/dir4
Expected results:
rmdir fails with EROFS. The directory should exist on all the bricks.
Actual results:
rmdir fails with EROFS but the directory is deleted from the hashed subvol.
RCA:
In dht_rmdir_cbk:
if (op_ret == -1) {
if ((op_errno != ENOENT) && (op_errno != ESTALE)) {
local->op_errno = op_errno;
local->op_ret = -1;
if (op_errno != EACCES)
local->need_selfheal = 1; <--
local->need_selfheal is set to 1 as op_errno is EROFS.
}
gf_uuid_unparse(local->loc.gfid, gfid);
gf_msg_debug (this->name, op_errno,
"rmdir on %s for %s failed."
"(gfid = %s)",
prev->this->name, local->loc.path,
gfid);
goto unlock;
}
However, local->fop_succeeded is still 0 as there are only 2 subvols.
} else if (this_call_cnt) {
/* If non-hashed subvol's have responded, proceed */
---> No check is performed here to see if the fop succeeded. rmdir is wound to
the hashed subvol and succeeds.
local->need_selfheal = 0;
STACK_WIND (frame, dht_rmdir_hashed_subvol_cbk,
local->hashed_subvol,
local->hashed_subvol->fops->rmdir,
&local->loc, local->flags, NULL);
} else if (!this_call_cnt) {
Now dir4 exists on the non-hashed subvol but not the hashed subvol.
ls dir1/dir2/dir3 shows no entries but rmdir dir1/dir2/dir3 returns ENOTEMPTY.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
More information about the Bugs
mailing list