Description of problem: async_pending directory should not be considered as a container inside the account, rather it should be handled as "tmp" directory inside the account. As this may give wrong about number of containers and objects, if a user tries HEAD over account. [root@QA-39 ~]# curl -v -H 'X-Auth-Token: AUTH_tk97edb64f5c034fb08097c94b27da92e2' http://10.16.157.63:8080/v1/AUTH_test * About to connect() to 10.16.157.63 port 8080 (#0) * Trying 10.16.157.63... connected * Connected to 10.16.157.63 (10.16.157.63) port 8080 (#0) > GET /v1/AUTH_test HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.12.9.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2 > Host: 10.16.157.63:8080 > Accept: */* > X-Auth-Token: AUTH_tk97edb64f5c034fb08097c94b27da92e2 > < HTTP/1.1 200 OK < X-Account-Container-Count: 5 < X-Account-Object-Count: 0 < X-Bytes-Used: 0 < X-Object-Count: 0 < X-Account-Bytes-Used: 0 < X-Type: Account < X-Container-Count: 5 < Accept-Ranges: bytes < Content-Length: 38 < Content-Type: text/plain; charset=utf-8 < Date: Wed, 06 Jun 2012 04:35:24 GMT < async_pending cont1 cont2 cont3 cont4 * Connection #0 to host 10.16.157.63 left intact * Closing connection #0 In the above example Container_count is 5, where as it should be 4. Version-Release number of selected component (if applicable): 3.3.0qa45 and swift-rc1-rpms How reproducible: always Steps to Reproduce: 1. 2. as mentioned above 3. Actual results: Expected results: Additional info:
The problem was with gluster-swift-plugin not filtering the asyc_pending container. Fixed it. Can be tested in the RHS2.0 rc2.
verified on rc2 rpms