Description of problem:
=======================
rm -rf from multiple mount points throws message "Is a directory". I didn't see any functionality impact when the issue is seen, rm -rf cleaned the mount point successfully without any left over dir/files.
rm: cannot remove ‘linux-4.9.27/Documentation/arm/keystone’: Is a directory
rm: cannot remove ‘linux-4.9.27/Documentation/zh_CN/video4linux’: Is a directory
rm: cannot remove ‘linux-4.9.27/Documentation/devicetree/bindings/arm/marvell’: Is a directory
rm: cannot remove ‘linux-4.9.27/Documentation/ia64’: Is a directory
rm: cannot remove ‘linux-4.9.27/Documentation/devicetree/bindings/iio/accel’: Is a directory
rm: cannot remove ‘linux-4.9.27/Documentation/devicetree/bindings/sram’: Is a directory
rm: cannot remove ‘linux-4.9.27/Documentation/devicetree/bindings/w1’: Is a directory
rm: cannot remove ‘linux-4.9.27/Documentation/devicetree/bindings/fuse’: Is a directory
rm: cannot remove ‘linux-4.9.27/arch/arm64/boot/dts/xilinx’: Is a directory
rm: cannot remove ‘linux-4.9.27/arch/arm64/boot/dts/exynos’: Is a directory
rm: cannot remove ‘linux-4.9.27/arch/nios2/lib’: Is a directory
rm: cannot remove ‘linux-4.9.27/arch/cris/boot/dts/include’: Is a directory
rm: cannot remove ‘linux-4.9.27/arch/cris/include/arch-v10/arch’: Is a directory
Version-Release number of selected component (if applicable):
3.12.2-4.el7rhgs.x86_64
How reproducible:
intermittently
Steps to Reproduce:
===================
1) Create a x3 volume and start it. (brick mux is enabled and md-cache is turned off)
2) FUSE mount on multiple clients.
3) Create large data set so that rm -rf takes more time.
4) Run rm -rf * from multiple clients (diff clients and multiple terminals from same client)
Actual results:
==============
rm -rf * throws message "Is a directory"
Expected results:
==================
rm -rf should not throw any errors.
Haven't heard from Geo-Rep team here. I would like to understand if this should be treated as a concern at all.
My vote is to make sure we don't treat it as a possible fix for 3.4.0 (ie, rm -rf from multiple mounts) as, this was an issue ever since DHT started, in every alternative releases.
Kotresh, Lets take a final decision on this tomorrow.
With geo-rep's perspective, yes it does parallel rm -rf from different mountpoints. But as per QE's testing, we are hitting ENOTEMPTY a lot frequently and not EISDIR. It becomes important w.r.t geo-rep if the error persists even after multiple retires. If it's transitional error, geo-rep is fine.
Comment 15RHEL Program Management
2018-05-24 07:32:48 UTC
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.