[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: zero-filed page on VOP_PUTPAGES
> 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.
what does FUSE protocol do to prevent unsafe reordering?
i guess we can learn from it.
> 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?
i guess the easiest way to fix is to serialize requests for a file.
it might be better to extend the puffs protocol so that the kernel can
explicitly tell file servers necessary request barriers, ie. which
requests can be safely reordered and which ones are not, so that userland
only need to perform minimal serialization.
> Emmanuel Dreyfus
Main Index |
Thread Index |