Hi Sebastien.

The problem here is that the deletion effectively occurred in the background while the client was reconnecting. Since xrootd is relatively stateless it would follow the client may get an ENOENT. The way we prevent this is to place the client in polling wait until the deletion has completed. Another way is to use client callbacks for long running tasks. However, “rm” does not support a callback (though we can add that pretty easily if you need it).

Andy

From: Sebastien Ponce
Sent: Monday, December 07, 2015 7:22 AM
To: xrootd/xrootd
Cc: Andrew Hanushevsky
Subject: Re: [xrootd] xrdfs retries too aggressive on rm (#315)

Well, my problem is not the timeout, I find it reasonable and I'm absolutely ready to accept a timeout error when the backend takes ages to drop a file. My problem is that the client view here is that it gets an ENOENT while the file was there and the deletion was done.

Concerning your curiosity, I'm using the radosstriper library to ceph, and the implementor (a nasty guy ;-)) did not take the time to optimize the deletion. It's a simple while loop on the objects doing deletions in a row and synchronously. With 5GB and thus thousands of objects, it's not really optimal... I'll improve that in the future.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1