Closed fbrau closed 5 months ago
.securefs.json
minus the keys here (or create a brand new repo to reproduce the issue and post the json here).🆗, 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.
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 https://github.com/docker/hub-feedback/issues/727 seems very similar and using bsdtar instead of tar works for me but I wonder what other things could be silently causing corruption
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.
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?
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.
You are not seeing in ls
because previously I don't fill in the st_ino
field in readdir. Now I do.
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?
Yes, the data are compatible between use_ino and not. It only changes what libfuse uses for its internal data structures.
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