Bug 829137 - object-storage: async_pending dir should not be considered as container
object-storage: async_pending dir should not be considered as container
Status: CLOSED CURRENTRELEASE
Product: GlusterFS
Classification: Community
Component: object-storage (Show other bugs)
pre-release
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Junaid
Saurabh
:
Depends On:
Blocks: 817967
  Show dependency treegraph
 
Reported: 2012-06-06 00:59 EDT by Saurabh
Modified: 2016-01-19 01:10 EST (History)
4 users (show)

See Also:
Fixed In Version: glusterfs-3.4.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-24 13:25:16 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions: 3.3.0 rc2
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Saurabh 2012-06-06 00:59:10 EDT
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:
Comment 1 Junaid 2012-06-13 04:31:08 EDT
The problem was with gluster-swift-plugin not filtering the asyc_pending container. Fixed it. Can be tested in the RHS2.0 rc2.
Comment 2 Saurabh 2012-06-20 00:41:26 EDT
verified on rc2 rpms

Note You need to log in before you can comment on or make changes to this bug.