failed to fully extract large tar file

[fbrau]

THIS SITUATION ONLY HAPPENS WHEN THE METADATA DIRECTORY RESIDES IN in-memory /tmp (tmpfs).

I dont know if this is directly related to securefs, I tried in gocryptfs and it runs flawlessly. But on secure's mount:

time tar xf linux-5.15.19.tar.xz && time sync
tar: linux-5.15.19/arch/arm64/boot/dts/arm: Directory renamed before its status could be extracted
tar: linux-5.15.19/arch/arm64/boot/dts: Directory renamed before its status could be extracted
tar: linux-5.15.19/arch/arm64/boot: Directory renamed before its status could be extracted
tar: linux-5.15.19/arch/arm64: Directory renamed before its status could be extracted
tar: Exiting with failure status due to previous errors

real 0m33.21s
user 0m21.24s
sys 0m06.66s

And this has effectively created corruption:

diff -uqr gomon/linux-5.15.19 secmon/linux-5.15.19
Files gomon/linux-5.15.19/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi and secmon/linux-5.15.19/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi differ
Files gomon/linux-5.15.19/scripts/dtc/include-prefixes/arm64/arm/vexpress-v2m-rs1.dtsi and secmon/linux-5.15.19/scripts/dtc/include-prefixes/arm64/arm/vexpress-v2m-rs1.dtsi differ

[netheril96]

• What is your OS and version?
• What is the securefs version?
• Please post the .securefs.json minus the keys here (or create a brand new repo to reproduce the issue and post the json here).

[netheril96]

🆗, I was able to reproduce the issue.

I can workaround it by adding --atrr-timeout=1 on the mount option. It looks like that libfuse has trouble caching too many inodes so a lower timeout can clear out the cache faster.

Please try to see if that works for you.

[fbrau]

• What is your OS and version?

  • What is the securefs version?

  • Please post the .securefs.json minus the keys here (or create a brand new repo to reproduce the issue and post the json here).

-Im running slackware 64 bits with kernel 5.15.145
-securefs version 0.14.3
-securefs.json
{
"argon2_m_cost" : 262144,
"argon2_p" : 4,
"block_size" : 4096,
"encrypted_key" :
{
"IV" : "192dd0775952751824dcf49a9f2f6b759b918295f36d10a6727ba6e1006a5bc3",
"MAC" : "8651a94ae8ef3d349f8f2baac609fa65",
"key" : "928f29abb6f52a8e1a3c13ecde7d3e7a74274000b83d69af0075f6b9434c9963df612aceaea8cf08177467765efc8d30b4d0b1d421b873e42147ec60c6188b17254d4cec1e3f80b17553451e9faec8d0f8055ad468d86410a5bb44a4e95e912b209a63be1a32f8514488f7276aaf737cbe373cfa3a9976594e6575aae67ab7ee"
},
"iterations" : 9,
"iv_size" : 12,
"pbkdf" : "argon2id",
"salt" : "ce6681c7c9052d970961713802545ccf6cc82c207f330cfec01f0fb9b2555e62",
"version" : 4
}

I have tried to frame the glitch but failed because its intermittent. Mount with --attr-timeout 1 but the error messages keep appearing from time to time. I also tried triggering /proc/sys/vm/drop_caches with similar results. This unrelated ticket docker/hub-feedback#727 seems very similar and using bsdtar instead of tar works for me but I wonder what other things could be silently causing corruption

[netheril96]

Can you try mount with -o use_ino without --attr-timeout and see if it still occurs? My guess is that GNU tar is inappropriately expecting a stable inode number which libfuse high level API doesn't usually guarantee.

[fbrau]

Can you try mount with -o use_ino without --attr-timeout and see if it still occurs? My guess is that GNU tar is inappropriately expecting a stable inode number which libfuse high level API doesn't usually guarantee.

With -o use_ino the filesystem gets quirky. A "ls" doesn't show files. If I "touch" a new file it doesn't get listed neither but if I do a "ls FILE" it does just like a "stat FILE" does too... If I "mkdir" a directory it doesnt appear with "ls" neither but I can "cd" into it. Is that behaviour normal?

[netheril96]

I pushed two commits on the branch use_ino that may solve the problem you see. If you don't want to compile it yourself, you can download the binary from GitHub Action. Please test it.

[netheril96]

You are not seeing in ls because previously I don't fill in the st_ino field in readdir. Now I do.

[fbrau]

Sorry the delay to answer I had many inconvenients in the week and I also wanted to take a couple of days at least to test many times with different system loads. The default mount options dont always trigger tar error, but it consistently got triggered when the system was paging. And when it got triggered it also got triggered on the next test iteration. The use_ino mode (with the last bugfixes) on the other hand never triggered the error.

The issue seems solved to me.

Data encrypted with use_ino mode is 100% compatible with the default settings, right?

[netheril96]

Yes, the data are compatible between use_ino and not. It only changes what libfuse uses for its internal data structures.