S3QL S3互換ストレージが正常にアンマウントできない場合

今回は、S3QLでマウントするストレージに”S3互換ストレージ”を指定した時に遭遇したエラーについて。

具体的には、S3QLでS3互換ストレージをマウントし、データを書き込み、アンマウントしたところ下記のようなエラーが出力されて、その後マウントできない状況になりました。
※マウントする前に、fsck.s3qlをかけても同様のエラーが出力されてしまいます

＜アンマウント時のログから抜粋＞

2015-07-20 11:33:59.949 16110:MainThread s3ql.mount.main: FUSE main loop terminated.
2015-07-20 11:33:59.954 16110:MainThread s3ql.mount.unmount: Unmounting file system...
2015-07-20 11:34:03.042 16110:MainThread s3ql.mount.main: Dumping metadata...
2015-07-20 11:34:03.042 16110:MainThread s3ql.metadata.dump_metadata: ..objects..
2015-07-20 11:34:03.044 16110:MainThread s3ql.metadata.dump_metadata: ..blocks..
2015-07-20 11:34:03.045 16110:MainThread s3ql.metadata.dump_metadata: ..inodes..
2015-07-20 11:34:03.046 16110:MainThread s3ql.metadata.dump_metadata: ..inode_blocks..
2015-07-20 11:34:03.046 16110:MainThread s3ql.metadata.dump_metadata: ..symlink_targets..
2015-07-20 11:34:03.047 16110:MainThread s3ql.metadata.dump_metadata: ..names..
2015-07-20 11:34:03.048 16110:MainThread s3ql.metadata.dump_metadata: ..contents..
2015-07-20 11:34:03.049 16110:MainThread s3ql.metadata.dump_metadata: ..ext_attributes..
2015-07-20 11:34:03.050 16110:MainThread s3ql.mount.main: Compressing and uploading metadata...
2015-07-20 11:34:03.105 16110:MainThread s3ql.mount.main: Wrote 321 bytes of compressed metadata.
2015-07-20 11:34:03.105 16110:MainThread s3ql.mount.main: Cycling metadata backups...
2015-07-20 11:34:03.105 16110:MainThread s3ql.metadata.cycle_metadata: Backing up old metadata...
2015-07-20 11:34:03.331 16110:MainThread s3ql.backends.s3c.copy: Unexpected server reply to copy operation:
200 OK
Server: Riak CS
ETag: "5df94930a7549cfcd6acab482c9bae94"
Date: Wed, 08 Jul 2015 02:34:03 +0000
Content-Type: application/xml
Content-Length: 175

解決策を探していたところ以下の記述を見つけました。

＜ソースに含まれるChanges.txtより＞

2014-11-09, S3QL 2.12
  * The s3c backend has a new 'dumb-copy' option. If this option
    is enabled, copy operations are assumed to have succeeded
    as soon as the server returns a '200 OK' status, without
    checking the contents of the response body.

＜http://www.rath.org/s3ql-docs/backends.html　のS3 compatibleの項目より＞

dumb-copy

If this option is specified, S3QL assumes that a COPY request to the storage server has succeeded as soon as the server returns a 200 OK status. The S3 COPY API specifies that the storage server may still return an error in the request body (see the copy proposal for the rationale), so this option should only be used if you are certain that your storage server only returns 200 OK when the copy operation has been completely and successfully carried out. Using this option may be neccessary if your storage server does not return a valid response body for a succesfull copy operation.

ということで最終的には、下記のようにmount.s3qlでマウント時に、バックエンドオプションをプラスする事で解決できました。

# mount.s3ql --allow-other --backend-options=dumb-copy \
> s3c://<hosstname or エンドポイント名など>/<backetname>/ /home/vmail