lkml.org 
[lkml]   [2021]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Canvassing for network filesystem write size vs page size
On Thu, Aug 05, 2021 at 05:35:33PM +0100, David Howells wrote:
> With Willy's upcoming folio changes, from a filesystem point of view, we're
> going to be looking at folios instead of pages, where:
>
> - a folio is a contiguous collection of pages;
>
> - each page in the folio might be standard PAGE_SIZE page (4K or 64K, say) or
> a huge pages (say 2M each);

This is not a great way to explain folios.

If you're familiar with compound pages, a folio is a new type for
either a base page or the head page of a compound page; nothing more
and nothing less.

If you're not familiar with compound pages, a folio contains 2^n
contiguous pages. They are treated as a single unit.

> - a folio has one dirty flag and one writeback flag that applies to all
> constituent pages;
>
> - a complete folio currently is limited to PMD_SIZE or order 8, but could
> theoretically go up to about 2GiB before various integer fields have to be
> modified (not to mention the memory allocator).

Filesystems should not make an assumption about this ... I suspect
the optimum page size scales with I/O bandwidth; taking PCI bandwidth
as a reasonable proxy, it's doubled five times in twenty years.

> Willy is arguing that network filesystems should, except in certain very
> special situations (eg. O_SYNC), only write whole folios (limited to EOF).

I did also say that the write could be limited by, eg, a byte-range
lease on the file. If the client doesn't have permission to write
a byte range, then it doesn't need to write it back.

\
 
 \ /
  Last update: 2021-08-06 01:48    [W:0.134 / U:2.700 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site