Hi, On Sep 22 10:45 AM, Aaron Straus wrote: > > diff --git a/fs/nfs/write.c b/fs/nfs/write.c > > index 3229e21..eb6b211 100644 > > --- a/fs/nfs/write.c > > +++ b/fs/nfs/write.c > > @@ -1428,7 +1428,8 @@ static int nfs_write_mapping(struct address_space *mapping, int how) > > .sync_mode = WB_SYNC_NONE, > > .nr_to_write = LONG_MAX, > > .for_writepages = 1, > > - .range_cyclic = 1, > > + .range_start = 0, > > + .range_end = LLONG_MAX, > > }; > > int ret; > > > > Also, I should test this, but I thought the VM was calling > nfs_writepages directly i.e. not going through nfs_write_mapping. Let > me test with this patch. Yes. This patch doesn't seem to help. The VM is calling nfs_writepages directly. I have debug statements in the nfs_write_mapping() call and it hasn't been called when the hole appears. It's the VM dirty page writeout that is happening out of order, *not* nfs_wb_* stuff. That's why we can see it so easily. The dirty pages are only scanned periodically. In-between scans is when we see the hole. I think :). I'm obviously not an expert here. Thanks, =a= -- =================== Aaron Straus aaron@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
