Hi,
On 2024/1/24 13:05, Matthew Wilcox wrote:
On Wed, Oct 18, 2023 at 09:25:18AM -0300, Wedson Almeida Filho wrote:
+config TARFS_FS
+ tristate "TAR file system support"
+ depends on RUST && BLOCK
+ select BUFFER_HEAD
I didn't spot anywhere in this that actually uses buffer_heads. Why
did you add this select?
Side node: I think sb.read() relies on
"[RFC PATCH 15/19] rust: fs: add basic support for fs buffer heads"
More background:
Although I'm unintended to join a new language interface
discussion, which I'm pretty neutral. But I might need to add some
backgrounds about the "tarfs" itself since I'm indirectly joined
some discussion.
The TarFS use cases has been discussed many times in
"confidential containers" for almost a year in their community
meeting to passthrough OCI images to guests but without an
agreement.
And this "TarFS" once had a C version which was archived at
https://github.com/kata-containers/tardev-snapshotter/blob/main/tarfs/tarfs.c
and the discussion was directly in a Kata container PR:
https://github.com/kata-containers/kata-containers/pull/7106#issuecomment-1592192981
IMHO, this "tarfs" implementation have no relationship with the
real tar on-disk format since it defines a new customized index
format rather than just parse tar in kernel.
IOWs, "tarfs" mode can be directly supported by using EROFS since
Linux v6.3 by using 512-byte block size addressing, see
https://git.kernel.org/torvalds/c/61d325dcbc05
And I think any local fs which supports 512-byte block size can
have a "tarfs" mode without any compatibility issue.
BTW, in addition to incompatiable with on-disk tar format, this
tarfs does not seem to support tar xattrs too.
Thanks,
Gao Xiang
