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.
