On Fri, Mar 4, 2022 at 11:30 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Fri, 4 Mar 2022 at 07:23, Jiachen Zhang > <zhangjiachen.jaycee@xxxxxxxxxxxxx> wrote: > > > I tested this fix, and it did pass the xfstests generic/464 in our > > Thanks for testing! > > > environment. However, if I understand correctly, one of the usages of > > the nowrite is to protect file truncation, as said in the commit > > message of e4648309b85a78f8c787457832269a8712a8673e. So, does that > > mean this fix may introduce some other problems? > > That's an excellent question. I don't think this will cause an issue, > since the nowrite protection is for truncation of the file on the > server (userspace) side. The inode lock still protects concurrent > writes against page cache truncation in the writeback cache case. In > the non-writeback cache case the nowrite protection does not do > anything. Got it. So the nowrite is protecting O_TRUNC FUSE_OPEN (or truncating FUSE_SETATTR) against FUSE_WRITE in writeback_cache mode? Then this patch looks good to me. Thanks, Jiachen > > Thanks, > Miklos