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.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.