Windkit Li
Windkit Li
## Issue Summary Directory deletion is done asynchronously, if the directory is re-created afterwards, incorrect deletion will happen, similar to the bucket case https://github.com/leo-project/leofs/issues/150 [spark_fail_sinfo.txt](https://github.com/leo-project/leofs/files/1123488/spark_fail_sinfo.txt) [spark_fail_access.txt](https://github.com/leo-project/leofs/files/1123489/spark_fail_access.txt) [spark_fail_info.txt](https://github.com/leo-project/leofs/files/1123490/spark_fail_info.txt) [spark_fail_saccess.txt](https://github.com/leo-project/leofs/files/1123491/spark_fail_saccess.txt) ## Related...
Issue fixed with Spark 2.2.0 + Hadoop 2.7.3 and Spark 1.6.1 + Hadoop 2.6.3 with hadoop-aws-2.7.3.jar and aws-java-sdk-1.7.4.jar
With s3a:// available, it may be possible to use `cp` / `distcp` to copy file to/from hadoop ``` https://community.hortonworks.com/questions/7165/how-to-copy-hdfs-file-to-aws-s3-bucket-hadoop-dist.html ``` TODO - [ ] Test cp/distcp
As a first test, I tested the scenario when Manager are down The performance is very close to normal case Report at: https://github.com/leo-project/notes/tree/master/leofs/benchmark/leofs/1.3/1.3.3/front/20170331_image_f4m_load_read_manager_30min_1 ### Load #### Normal  ####...
As a first step (easy hack?), we can handle the GET Object ACL Request by replying the ACL of Bucket
@mocchira The previous fix only works when the object is not cached, I am creating a PR
[access.log.txt](https://github.com/leo-project/leofs/files/1086674/access.log.txt) s3ql (https://bitbucket.org/nikratio/s3ql/) makes use of the bucket-get with prefix in startup, this issue is a blocker for using s3ql with LeoFS
From my experience, catergorizing data into timestamped buckets do help much in data expiration!
@yosukehara @mocchira Sorry that I mixed the result for 200KB with the 100KB. Here I presented the results with 200KB, read from 1MB, 50MB, 200KB (Whole Object) to make it...
The call down to `leo_object_storage` does not limit the number of keys returned, probably the cause of long operation https://github.com/leo-project/leofs/blob/develop/apps/leo_storage/src/leo_storage_handler_object.erl#L968