0

我正在做一些奇怪的事情，创建一个overlayfs挂载，其中较低的目录是一个FUSE卷（我已经实现了）。这似乎主要工作，我可以通过overlayfs挂载从FUSE挂载读取文件，并且它们具有正确的内容。我还可以在 overlayfs 挂载中创建新文件，这并不奇怪，因为这应该只要求较低的 FUSE 层ENOENT在您尝试LOOKUP那个文件。失败的是当我尝试附加到现有文件时，而不是获取现有内容后跟附加内容，我只是获取附加内容。我假设一定有我的 FUSE 卷应该做的事情，它不是，这导致了这个错误。但是，查看日志并没有抱怨任何未实现的方法，也没有任何错误。以下是相关文件（“foo”）的日志。

2020/04/15 10:35:42 rx 9: LOOKUP i9223372036854775808 ["foo"] 4b
2020/04/15 10:35:42 tx 9:     OK, {i9223372036854775809 g0 tE=0s tA=0s {M0100644 SZ=0 L=0 0:0 B0*0 i0:9223372036854775809 A 0.000000 M 0.000000 C 0.000000}}
2020/04/15 10:35:42 rx 10: OPEN i9223372036854775809 {O_RDONLY,0x8000}
2020/04/15 10:35:42 tx 10:     OK, {Fh 1 }
2020/04/15 10:35:42 rx 11: GETATTR i9223372036854775809 {Fh 0}
2020/04/15 10:35:42 tx 11:     OK, {tA=0s {M0100600 SZ=4 L=1 0:0 B8*4096 i0:9223372036854775809 A 1586972142.827290 M 1586972142.855292 C 1586972142.855292}}
2020/04/15 10:35:42 rx 12: GETATTR i9223372036854775809 {Fh 1}
2020/04/15 10:35:42 tx 12:     OK, {tA=0s {M0100600 SZ=4 L=1 0:0 B8*4096 i0:9223372036854775809 A 1586972142.827290 M 1586972142.855292 C 1586972142.855292}}
2020/04/15 10:35:42 rx 13: READ i9223372036854775809 {Fh 1 [0 +4096)  L 0 NONBLOCK,0x8000}
2020/04/15 10:35:42 tx 13:     OK,  4096b data (fd data)
2020/04/15 10:35:42 rx 14: GETATTR i9223372036854775809 {Fh 1}
2020/04/15 10:35:42 tx 14:     OK, {tA=0s {M0100600 SZ=4 L=1 0:0 B8*4096 i0:9223372036854775809 A 1586972142.855292 M 1586972142.855292 C 1586972142.855292}}
2020/04/15 10:35:42 rx 15: FLUSH i9223372036854775809 {Fh 1}
2020/04/15 10:35:42 tx 15:     OK
2020/04/15 10:35:42 rx 16: RELEASE i9223372036854775809 {Fh 1 NONBLOCK,0x8000  L0}
2020/04/15 10:35:42 tx 16:     OK
2020/04/15 10:35:42 rx 17: GETATTR i9223372036854775808 {Fh 0}
2020/04/15 10:35:42 tx 17:     OK, {tA=0s {M040755 SZ=0 L=0 0:0 B0*0 i0:9223372036854775808 A 0.000000 M 0.000000 C 0.000000}}
2020/04/15 10:35:42 rx 18: LISTXATTR i9223372036854775808 {sz 0}
2020/04/15 10:35:42 tx 18:     OK
2020/04/15 10:35:42 rx 19: GETATTR i9223372036854775809 {Fh 0}
2020/04/15 10:35:42 tx 19:     OK, {tA=0s {M0100644 SZ=0 L=0 0:0 B0*0 i0:9223372036854775809 A 0.000000 M 0.000000 C 0.000000}}
2020/04/15 10:35:42 rx 20: LISTXATTR i9223372036854775809 {sz 0}
2020/04/15 10:35:42 tx 20:     OK

如果这很重要，保险丝层是用 go 编写的。

4

1 回答 1

1

首先，这个设置并不奇怪。其次，您将有更好的机会在 linux-unionfs@vger.kernel.org 上获得答案。

但无论如何，据我所知，问题似乎出在你的保险丝 fs 上：

2020/04/15 10:35:42 rx 9：查找 i9223372036854775808 [“foo”] 4b 2020/04/15 10:35:42 tx 9：好的，{i9223372036854775809 g0 tE=0s 46 S=0s {M0100 = L=0 0:0 B0*0 i0:9223372036854775809 A 0.000000 M 0.000000 C 0.000000}}

2020/04/15 10:35:42 rx 19：GETATTR i9223372036854775809 {Fh 0} 2020/04/15 10:35:42 tx 19：OK，{tA=0s {M0100644 SZ=0 L=0 0:0 B0 *0 i0:9223372036854775809 A 0.000000 M 0.000000 C 0.000000}}

不知道为什么，但是您的 fs 将查找时发现的文件大小报告为零，而稍后在读取文件时，大小正确报告为 4。

我希望如果您在 fuse fs 上运行 stat(1) 或 ls -l 您也可能会观察到这个问题。可能是您正确实现了 fstat(2) 而不是 lstat(2)？

谢谢，阿米尔。

于 2020-04-16T07:41:11.593 回答