Skip to contentSkip to conversation

: Btrfs: Decoupling block-size and page-size in BTRFS.

LSF/MM TOPIC Chandan Rajendra 3 participants 3 messages Nov 27, 2014 – Dec 1, 2014

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

In BTRFS, BLOCK_SIZE, the basic IO size of the filesystem, is equal to the PAGE_SIZE of the architecture. Some 64-bit architectures, like PPC64 and ARM64, can/do have a default PAGE_SIZE of 64K, which means the filesystems handled in these architectures have a BLOCK_SIZE of 64K.

This works fine as long as you create and use the filesystems within these systems. But users cannot create a filesystem in an architecture of a specific BLOCK_SIZE and then use that filesystem in another. So a filesystem created on x86 cannot be used (mounted, read, ...) on a PPC64 or ARM64 system.

9 versions of the subpagesize-blocksize patchset have been posted until today (see
https://www.mail-archive.com/[email protected]/msg38862.html). These patches address only the issues in regular I/O code path of Btrfs and still needs more work to get it working correctly. Other Btrfs features (e.g. compression, scrub, etc) also need some work to get them working in subpagesize-blocksize scenario.

I believe that a face-to-face discussion involving Btrfs maintainers/developers to address some of the design issues would enable us to fast track the inclusion of this feature into the mainline kernel tree.

Signature · 1 line
chandan
#1 lore raw

Is this topic relevant for the broarder FS community? Maybe the btrfs community should look into organizing a meeting co-hosted with Vault similar to what we did for ext4 and XFS in the past?

#2 lore raw
Quoted 3 lines · Christoph Hellwig

Is this topic relevant for the broarder FS community? Maybe the btrfs community should look into organizing a meeting co-hosted with Vault similar to what we did for ext4 and XFS in the past?

Yeah, this is a very btrfs specific topic. I'm happy to organize an official Btrfs sub-topic as part of vault or LSF.

-chris