Overlayfs copy-up создает пустой файл

Question

Я делаю что-то довольно странное, создавая монтирование overlayfs, в котором нижний каталог является томом FUSE (который я реализовал). Кажется, это в основном работает, я могу читать файлы с монтирования FUSE через монтирование overlayfs, и у них есть правильный контент. Я также могу создавать новые файлы в монтировании 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

Слой предохранителей написан на ходу, если это вообще имеет значение.

Answer 1

Во-первых, это не так уж и странно. Во-вторых, у вас будет гораздо больше шансов получить ответ на [e-mail].

Но в любом случае, насколько я могу судить, проблема, похоже, в вашем предохранителе fs:

2020/04/15 10:35:42 rx 9: LOOKUP i9223372036854775808 ["foo"] 4b 2020/04/15 10:35:42 tx 9: ОК, {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 19: GETATTR i9223372036854775809 {Fh 0}2020/04/15 10:35:42 tx 19: ОК, {tA = 0s {M0100644 SZ=0 L= 0 0: 0 B0* 0 i0: 9223372036854775809 A 0,000000 M 0,000000 C 0,000000}}

Не уверен, почему, но ваша fs сообщает, что размер файла, найденного при поиске, равен нулю, а позже, при чтении файла, размер сообщается правильно как 4.

Я ожидаю, что если вы запустите stat(1) или ls -l на своем fuse fs, вы также можете столкнуться с этой проблемой. Может быть, вы правильно реализовали fstat(2), но не lstat(2)?

Спасибо, Амир.