Re: zero-filed page on VOP_PUTPAGES

[manu%netbsd.org@localhost (Emmanuel Dreyfus)]

YAMAMOTO Takashi <yamt%mwd.biglobe.ne.jp@localhost> wrote:

> well, does it process puffs requests from kernel out-of-order?


Yes. operation the touch the size can wait for others to complete before
returning. Below is an example of SETATTR/GETATTR requests with the replies
ordered the other way around. This is a PUFFS dump with FUSE dump marked
FUSE> for requests and FUSE< for replies. Note that reordering does happen in
the FUSE filesystem: perfused sent requests with the correct order here.

This is probably where my bug lies: here SETATTR sets size to 18087, and the
file gets a zeroed chunk of 18087 at offset 0.

        reqid: 928, opclass 2, optype: PUFFS_VN_SETATTR, cookie: 0xbb90f3e0,
                aux: 0xbb91f02c, auxlen: 240, pid: 0, lwpid: 27
                size: 18087/0x46a7
                since previous call: 0.117096
FUSE> unique = 890, nodeid = 3101688548, opcode = SETATTR (4)
        reqid: 929, opclass 2, optype: PUFFS_VN_GETATTR, cookie: 0xbb90f3e0,
                aux: 0xbb92002c, auxlen: 240, pid: 6048, lwpid: 1
                since previous call: 0.002735
FUSE> unique = 891, nodeid = 3101688548, opcode = GETATTR (3)
FUSE< unique = 891, nodeid = 3101688548, opcode = GETATTR (3), error = 0
        RV reqid: 929, result: 0 
FUSE< unique = 890, nodeid = 3101688548, opcode = SETATTR (4), error = 0
        RV reqid: 928, result: 0 

> puffs protocol lacks request serializations.

The big question is: can that be fixed?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu%netbsd.org@localhost