fix: keep meta data complete

[Ace-Tang]

before updating meta.json on disk, write a new file for the new content, in case
that if it fails to write new file(like no space on disk), we can still
have a completed file. Avoid meta.json broken, in this way, we may
hardly recover meta data
Signed-off-by: Ace-Tang aceapril@126.com

Ⅰ. Describe what this PR did

The design

1. use timestamp as a suffix of a backfile, consider that if one time back up file is not deleted, backup file will be covered, generally it will be ok, but sometimes it may error.
2. do not use backup file to do recovery automatically, first this case is really unusual, if it happens, we should check and do recovery by manual. If automatic recovery fails, we may never get origin file. So I do not suggest automatic recovery.

Design has changed according to the review, please check.

Ⅱ. Does this pull request fix one issue?

Ⅲ. Why don't you add test cases (unit test/integration test)? (你真的觉得不需要加测试吗？)

no.

Ⅳ. Describe how to verify it

Ⅴ. Special notes for reviews

[codecov]

Codecov Report

Merging #2292 into master will decrease coverage by 0.05%.
The diff coverage is 33.33%.

@@            Coverage Diff             @@
##           master    #2292      +/-   ##
==========================================
- Coverage    66.8%   66.74%   -0.06%     
==========================================
  Files         208      208              
  Lines       16971    16974       +3     
==========================================
- Hits        11337    11330       -7     
- Misses       4270     4275       +5     
- Partials     1364     1369       +5

Flag	Coverage Δ
#criv1alpha1test	32.33% <33.33%> (-0.28%)	⬇️
#criv1alpha2test	36.03% <33.33%> (-0.19%)	⬇️
#integrationtest	39.46% <33.33%> (-0.01%)	⬇️
#nodee2etest	33.42% <33.33%> (+0.01%)	⬆️
#unittest	23.76% <33.33%> (ø)	⬆️

Impacted Files	Coverage Δ
pkg/meta/local.go	63% <33.33%> (-0.92%)	⬇️
cri/v1alpha2/cri_wrapper.go	61.2% <0%> (-1.2%)	⬇️
ctrd/container.go	58.8% <0%> (-0.96%)	⬇️
cri/v1alpha1/cri.go	61.27% <0%> (-0.33%)	⬇️
cri/v1alpha2/cri.go	66.76% <0%> (-0.3%)	⬇️
daemon/mgr/container.go	57.43% <0%> (-0.21%)	⬇️
daemon/containerio/cri_log_file.go	88.23% <0%> (+3.92%)	⬆️
daemon/mgr/snapshot.go	94.2% <0%> (+4.34%)	⬆️

[allencloud]

Is there any possibility that before backuping the original meta.json, the disk have already been full, and then the backup fails？ @Ace-Tang

[Ace-Tang]

Is there any possibility that before backuping the original meta.json, the disk have already been full, and then the backup fails？ @Ace-Tang

it will return error, then, meta data update also fails.

if _, err := os.Stat(name); err == nil {
+               if err := os.Rename(name, backupFile); err != nil {
+                       return fmt.Errorf("failed to backup file %s: %s", name, err)
+               }
+       }
+

And if the container is first time to be created, the created process will fail, since disk is full.

[Ace-Tang]

@allencloud , modify as you suggest offline, PTAL.

[xiaoxubeii]

I think you should adjust the content of pr according to your recently changes. These changes don't backup the original configuration but create a new target file and replace the origin.

[Ace-Tang]

@xiaoxubeii ， I have alreay update content of pr, but just not update the auto-generated one, now I update it.

[allencloud]

LGTM, while I would invite @fuweid to take another review.

[rudyfly]

LGTM