Cause: When a large file with large number of shards is deleted, shard translator synchronously sends unlink operation on all the shards in parallel. This in turn causes replicate translator to acquire locks on .shard directory in parallel. Consequence: After a while, when a huge number of locks get accumulated in locks translator, the search for a possible matching lock gets slower, sometimes taking several minutes to complete, causing timeouts and leading to disconnects and subsequent failure of file deletion leading to stale shards being left out under .shard. Workaround (if any): For one, it is important that the customer uses 64MB as the shard block size. The lower the shard-block-size, the higher the chances of timeouts. And then if the issue is still hit with 64MB shards, the ghost shards can be identified and deleted from the backend of each brick after figuring out the gfid of the image on which deletion failed. Result: This way all the space consumed by ghost shards can be reclaimed.