On 9/18/23 01:14, Matthew Wilcox wrote:
On Mon, Sep 18, 2023 at 08:38:37AM +1000, Dave Chinner wrote:
On Fri, Sep 15, 2023 at 02:32:44PM -0700, Luis Chamberlain wrote:
LBS devices. This in turn allows filesystems which support bs > 4k to be
enabled on a 4k PAGE_SIZE world on LBS block devices. This alows LBS
device then to take advantage of the recenlty posted work today to enable
LBS support for filesystems [0].
Why do we need LBS devices to support bs > ps in XFS?
It's the other way round -- we need the support in the page cache to
reject sub-block-size folios (which is in the other patches) before we
can sensibly talk about enabling any filesystems on top of LBS devices.
Even XFS, or for that matter ext2 which support 16k block sizes on
CONFIG_PAGE_SIZE_16K (or 64K) kernels need that support first.
[snipping the parts I agree with; this should not be the first you're
hearing about a format change to XFS]
There might be a better way to do this than do deal with the switching
of the aops dynamically, ideas welcomed!
Is it even safe to switch aops dynamically? We know there are
inherent race conditions in doing this w.r.t. mmap and page faults,
as the write fault part of the processing is directly dependent
on the page being correctly initialised during the initial
population of the page data (the "read fault" side of the write
fault).
Hence it's not generally considered safe to change aops from one
mechanism to another dynamically. Block devices can be mmap()d, but
I don't see anything in this patch set that ensures there are no
other users of the block device when the swaps are done. What am I
missing?
We need to evict all pages from the page cache before switching aops to
prevent misinterpretation of folio->private. If switching aops is even
the right thing to do. I don't see the problem with allowing buffer heads
on block devices, but I haven't been involved with the discussion here.
Did we even have that conversation?
That's one of the first things I've stumbled across when doing my
patchset, and found the implications too horrible to consider.
Not a big fan, plus I don't think we need that.
Cf my patchset :-)
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman
