compaction eating data (leofs 1.0.0/1.0.1)

[Licenser]

Running a compaction on a storage node that is not affected by the 'loosing data after restart' causes the compaction to eat up data:

Initial (good) state:

du ny4_leo_st_1@172.21.0.206
 active number of objects: 2220
  total number of objects: 2220
   active size of objects: 6322709986.0
    total size of objects: 6322709986.0
     ratio of active size: 100.0%
    last compaction start: 2014-05-07 08:33:33 +0000
      last compaction end: 2014-05-07 08:33:34 +0000

run compaction

du ny4_leo_st_1@172.21.0.206
 active number of objects: 347
  total number of objects: 347
   active size of objects: 7401342874.0
    total size of objects: 7401342874.0
     ratio of active size: 100.0%
    last compaction start: 2014-05-08 14:36:39 +0000
      last compaction end: 2014-05-08 14:36:39 +0000

run compaction

du ny4_leo_st_1@172.21.0.206
 active number of objects: 139
  total number of objects: 139
   active size of objects: 145696125.0
    total size of objects: 145696125.0
     ratio of active size: 100.0%
    last compaction start: 2014-05-08 14:55:37 +0000
      last compaction end: 2014-05-08 14:55:37 +0000

The data is now nice and compact but regarding to the s3 API also all data is deleted :(

[yosukehara]

Thank you for your report.

It would be great if you share each storage error-logs because we would like to catch up this situation (we did not face that, yet).

[Licenser]

Sorry but there were no logs, that was the first thing I checked, emptied out the error log and ran the compaction, not a single line was written :(

[yosukehara]

I've fixed this issue. From now, we'll make the test codes, then it will be included in leo_object_storage/test.
Also, you're able to recover data of the storage-node with the recover node $node command.

• reference: recover - Recover target node’s objects and RING synchronization

So we're planning to release v1.0.2 soon.