Re: [PATCH RFC 0/2] btrfs: defrag: further preparation for multi-page sector size

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 2024/1/24 16:13, Matthew Wilcox wrote:
On Wed, Jan 24, 2024 at 03:57:39PM +1030, Qu Wenruo wrote:


On 2024/1/24 15:18, Matthew Wilcox wrote:
On Wed, Jan 24, 2024 at 02:33:22PM +1030, Qu Wenruo wrote:
I'm pretty sure we would have some filesystems go utilizing larger folios to
implement their multi-page block size support.

Thus in that case, can we have an interface change to make all folio
versions of filemap_*() to accept a file offset instead of page index?

You're confused.  There's no change needed to the filemap API to support
large folios used by large block sizes.  Quite possibly more of btrfs
is confused, but it's really very simple.  index == pos / PAGE_SIZE.
That's all.  Even if you have a 64kB block size device on a 4kB PAGE_SIZE
machine.

Yes, I understand that filemap API is always working on PAGE_SHIFTed index.

OK, good.

The concern is, (hopefully) with more fses going to utilized large
folios, there would be two shifts.

One folio shift (ilog2(blocksize)), one PAGE_SHIFT for filemap interfaces.

Don't shift the file position by the folio_shift().  You want to support
large(r) folios _and_ large blocksizes at the same time.  ie 64kB might
be the block size, but all that would mean would be that folio_shift()
would be at least 16.  It might be 17, 18 or 21 (for a THP).

Indeed, I forgot we have THP.


Filesystems already have to deal with different PAGE_SIZE, SECTOR_SIZE,
fsblock size and LBA size.  Folios aren't making things any worse here
(they're also not making anything better in this area, but I never
claimed they would).

OK, that makes sense.

So all the folio shifts would be an fs internal deal, and we have to handle it properly.


btrfs is slightly unusual in that it defined PAGE_SIZE and fsblock size
to be the same (and then had to deal with the consequences of arm64/x86
interoperability later).  But most filesystems have pretty good separation
of the four concepts.

Indeed, although I also found most major fses do not support larger block size (> PAGE_SIZE) either.

I guess subpage is simpler in the past, and hopefully with larger folio, we can see more fses support multi-page blocksize soon.

Thanks,
Qu

Attachment: OpenPGP_0xC23D91F3A125FEA8.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux