On Thu, 2007-11-15 at 17:10 +0100, Miklos Szeredi wrote:

quoted text
> Fuse page writeback design
> --------------------------
> 
> fuse_writepage() allocates a new temporary page with
> GFP_NOFS|__GFP_HIGHMEM.  It copies the contents of the original page,
> and queues a WRITE request to the userspace filesystem using this temp
> page.
> 
> From the VM's point of view, the writeback is finished instantly: the
> page is removed from the radix trees, and the PageDirty and
> PageWriteback flags are cleared.
> 
> The per-bdi writeback count is not decremented until the writeback
> truly completes.  And there's a new 'nr_writeback_temp' counter, that
> is used to track the global count of these writebacks instead of the
> per-zone NR_WRITEBACK (it could be a new per-zone counter in vm_stat,
> but for simplicity, current code just uses a single atomic counter).
> 
> If the writeout was due to memory pressure, in effect this migrates
> data from a full zone to a less full zone.
> 
> On dirtying the page, fuse waits for a previous write to finish before
> proceeding.  This makes sure, there can only be one temporary page used
> at a time for one cached page.
> 
> This approach is wasteful in both memory and CPU bandwidth, so why is
> this complication needed?
> 
> The basic problem is that there can be no guarantee about the time in
> which the userspace filesystem will complete a write.  It may be buggy
> or even malicious, and fail to complete WRITE requests.  We don't want
> unrelated parts of the system to grind to a halt in such cases.
> 
> Also a filesystem may need additional resources (particularly memory)
> to complete a WRITE request.  There's a great danger of a deadlock if
> that allocation may wait for the writepage to finish.
> 
> Currently there are several cases where the kernel can block on page
> writeback:
> 
>   - allocation order is larger than PAGE_ALLOC_COSTLY_ORDER
>   - page migration
>   - throttle_vm_writeout (through NR_WRITEBACK)
>   - sync(2)
> 
> Of course in some cases (fsync, msync) we explicitly want to allow
> blocking.  So for these cases new code has to be added to fuse, since
> the VM is not tracking writeback pages for us any more.

I'm somewhat confused by the complexity. Currently we can already have a
lot of dirty pages from FUSE (up to the per BDI dirty limit - so
basically up to the total dirty limit).

How is having them dirty from mmap'ed writes different?



-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html