[PATCH v4 0/1] Enforce 4k sectorize by default for mkfs

[PATCH v4 0/1] Enforce 4k sectorize by default for mkfs

[Neal Gompa]

The Fedora Asahi SIG[0] is working on bringing up support for
Apple Silicon Macintosh computers through the Fedora Asahi Remix[1].

Apple Silicon Macs are unusual in that they currently require 16k
page sizes, which means that the current default for mkfs.btrfs(8)
makes a filesystem that is unreadable on x86 PCs and most other ARM
PCs.

This is now even more of a problem within Apple Silicon Macs as it is now
possible to nest 4K Fedora Linux VMs on 16K Fedora Asahi Remix machines to
enable performant x86 emulation[2] and the host storage needs to be compatible
for both environments.

Thus, I'd like to see us finally make the switchover to 4k sectorsize
for new filesystems by default, regardless of page size.

The initial test run by Hector Martin[3] at request of Qu Wenruo
looked promising[4], and we've been running with this behavior on
Fedora Linux since Fedora Linux 36 (at around 6.2) with no issues.

=== Changelog ===

v4: Fixed minor errors in the cover letter and patch subject

v3: Refreshed cover letter, rebased to latest, updated doc references for v6.7

v2: Rebased to latest, updated doc references for v6.6

Final v1: Collected Reviewed-by tags for inclusion.

RFC v2: Addressed documentation feedback

RFC v1: Initial submission

[0]: https://fedoraproject.org/wiki/SIGs/Asahi
[1]: https://fedora-asahi-remix.org/
[2]: https://sinrega.org/2023-10-06-using-microvms-for-gaming-on-fedora-asahi/
[3]: https://lore.kernel.org/linux-btrfs/fdffeecd-964f-0c69-f869-eb9ceca20263@suse.com/T/#m11d7939de96c43b3a7cdabc7c568d8bcafc7ca83
[4]: https://lore.kernel.org/linux-btrfs/fdffeecd-964f-0c69-f869-eb9ceca20263@suse.com/T/#mf382b78a8122b0cb82147a536c85b6a9098a2895

Neal Gompa (1):
  btrfs-progs: mkfs: Enforce 4k sectorsize by default

 Documentation/Subpage.rst    | 15 ++++++++-------
 Documentation/mkfs.btrfs.rst | 13 +++++++++----
 mkfs/main.c                  |  2 +-
 3 files changed, 18 insertions(+), 12 deletions(-)

-- 
2.39.2

[PATCH v4 1/1] btrfs-progs: mkfs: Enforce 4k sectorsize by default

[Neal Gompa]

We have had working subpage support in Btrfs for many cycles now.
Generally, we do not want people creating filesystems by default
with non-4k sectorsizes since it creates portability problems.

Signed-off-by: Neal Gompa <neal@gompa.dev>

Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
---
 Documentation/Subpage.rst    | 17 +++++++++--------
 Documentation/mkfs.btrfs.rst | 13 +++++++++----
 mkfs/main.c                  |  2 +-
 3 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/Documentation/Subpage.rst b/Documentation/Subpage.rst
index c762b6a3..1655ae7e 100644
--- a/Documentation/Subpage.rst
+++ b/Documentation/Subpage.rst
@@ -9,18 +9,19 @@ to the exactly same size of the block and page. On x86_64 this is typically
 pages, like 64KiB on 64bit ARM or PowerPC. This means filesystems created
 with 64KiB sector size cannot be mounted on a system with 4KiB page size.
 
-While with subpage support systems with 64KiB page size can create
-and mount filesystems with 4KiB sectorsize.  This still needs to use option "-s
-4k" option for :command:`mkfs.btrfs`.
+Since v6.7, filesystems are created with a 4KiB sectorsize by default,
+though it remains possible to create filesystems with other page sizes
+(such as 64KiB with the "-s 64k" option for :command:`mkfs.btrfs`). This
+ensures that new filesystems are compatible across other architecture
+variants using larger page sizes.
 
 Requirements, limitations
 -------------------------
 
-The initial subpage support has been added in v5.15, although it's still
-considered as experimental, most features are already working without problems.
-On a 64KiB page system filesystem with 4KiB sectorsize can be mounted and used
-as usual as long as the initial mount succeeds. There are cases a mount will be
-rejected when verifying compatible features.
+The initial subpage support has been added in v5.15. Most features are
+already working without problems. On a 64KiB page system, a filesystem with
+4KiB sectorsize can be mounted and used as long as the initial mount succeeds.
+Subpage support is used by default for systems with a non-4KiB page size since v6.7.
 
 Please refer to status page of :ref:`status-subpage-block-size` for
 compatibility.
diff --git a/Documentation/mkfs.btrfs.rst b/Documentation/mkfs.btrfs.rst
index 7e23b9f6..be4f49cb 100644
--- a/Documentation/mkfs.btrfs.rst
+++ b/Documentation/mkfs.btrfs.rst
@@ -122,10 +122,15 @@ OPTIONS
 -s|--sectorsize <size>
         Specify the sectorsize, the minimum data block allocation unit.
 
-        The default value is the page size and is autodetected. If the sectorsize
-        differs from the page size, the created filesystem may not be mountable by the
-        running kernel. Therefore it is not recommended to use this option unless you
-        are going to mount it on a system with the appropriate page size.
+        By default, the value is 4KiB, but it can be manually set to match the
+        system page size. However, if the sector size is different from the page
+        size, the resulting filesystem may not be mountable by the current
+        kernel, apart from the default 4KiB. Hence, using this option is not
+        advised unless you intend to mount it on a system with the suitable
+        page size.
+
+        .. note::
+                Versions prior to 6.7 set the sectorsize matching to the page size.
 
 -L|--label <string>
         Specify a label for the filesystem. The *string* should be less than 256
diff --git a/mkfs/main.c b/mkfs/main.c
index d984c995..0570c8f8 100644
--- a/mkfs/main.c
+++ b/mkfs/main.c
@@ -1384,7 +1384,7 @@ int BOX_MAIN(mkfs)(int argc, char **argv)
 	}
 
 	if (!sectorsize)
-		sectorsize = (u32)sysconf(_SC_PAGESIZE);
+		sectorsize = (u32)SZ_4K;
 	if (btrfs_check_sectorsize(sectorsize))
 		goto error;
 
-- 
2.41.0

Re: [PATCH v4 1/1] btrfs-progs: mkfs: Enforce 4k sectorsize by default

[Eric Curtin]

On Thu, 16 Nov 2023 at 16:10, Neal Gompa <neal@gompa.dev> wrote:
>
> We have had working subpage support in Btrfs for many cycles now.
> Generally, we do not want people creating filesystems by default
> with non-4k sectorsizes since it creates portability problems.
>
> Signed-off-by: Neal Gompa <neal@gompa.dev>
>
> Reviewed-by: Anand Jain <anand.jain@oracle.com>
> Reviewed-by: Qu Wenruo <wqu@suse.com>
> Reviewed-by: Josef Bacik <josef@toxicpanda.com>

Makes sense to me!

Reviewed-by: Eric Curtin <ecurtin@redhat.com>

Is mise le meas/Regards,

Eric Curtin

> ---
>  Documentation/Subpage.rst    | 17 +++++++++--------
>  Documentation/mkfs.btrfs.rst | 13 +++++++++----
>  mkfs/main.c                  |  2 +-
>  3 files changed, 19 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/Subpage.rst b/Documentation/Subpage.rst
> index c762b6a3..1655ae7e 100644
> --- a/Documentation/Subpage.rst
> +++ b/Documentation/Subpage.rst
> @@ -9,18 +9,19 @@ to the exactly same size of the block and page. On x86_64 this is typically
>  pages, like 64KiB on 64bit ARM or PowerPC. This means filesystems created
>  with 64KiB sector size cannot be mounted on a system with 4KiB page size.
>
> -While with subpage support systems with 64KiB page size can create
> -and mount filesystems with 4KiB sectorsize.  This still needs to use option "-s
> -4k" option for :command:`mkfs.btrfs`.
> +Since v6.7, filesystems are created with a 4KiB sectorsize by default,
> +though it remains possible to create filesystems with other page sizes
> +(such as 64KiB with the "-s 64k" option for :command:`mkfs.btrfs`). This
> +ensures that new filesystems are compatible across other architecture
> +variants using larger page sizes.
>
>  Requirements, limitations
>  -------------------------
>
> -The initial subpage support has been added in v5.15, although it's still
> -considered as experimental, most features are already working without problems.
> -On a 64KiB page system filesystem with 4KiB sectorsize can be mounted and used
> -as usual as long as the initial mount succeeds. There are cases a mount will be
> -rejected when verifying compatible features.
> +The initial subpage support has been added in v5.15. Most features are
> +already working without problems. On a 64KiB page system, a filesystem with
> +4KiB sectorsize can be mounted and used as long as the initial mount succeeds.
> +Subpage support is used by default for systems with a non-4KiB page size since v6.7.
>
>  Please refer to status page of :ref:`status-subpage-block-size` for
>  compatibility.
> diff --git a/Documentation/mkfs.btrfs.rst b/Documentation/mkfs.btrfs.rst
> index 7e23b9f6..be4f49cb 100644
> --- a/Documentation/mkfs.btrfs.rst
> +++ b/Documentation/mkfs.btrfs.rst
> @@ -122,10 +122,15 @@ OPTIONS
>  -s|--sectorsize <size>
>          Specify the sectorsize, the minimum data block allocation unit.
>
> -        The default value is the page size and is autodetected. If the sectorsize
> -        differs from the page size, the created filesystem may not be mountable by the
> -        running kernel. Therefore it is not recommended to use this option unless you
> -        are going to mount it on a system with the appropriate page size.
> +        By default, the value is 4KiB, but it can be manually set to match the
> +        system page size. However, if the sector size is different from the page
> +        size, the resulting filesystem may not be mountable by the current
> +        kernel, apart from the default 4KiB. Hence, using this option is not
> +        advised unless you intend to mount it on a system with the suitable
> +        page size.
> +
> +        .. note::
> +                Versions prior to 6.7 set the sectorsize matching to the page size.
>
>  -L|--label <string>
>          Specify a label for the filesystem. The *string* should be less than 256
> diff --git a/mkfs/main.c b/mkfs/main.c
> index d984c995..0570c8f8 100644
> --- a/mkfs/main.c
> +++ b/mkfs/main.c
> @@ -1384,7 +1384,7 @@ int BOX_MAIN(mkfs)(int argc, char **argv)
>         }
>
>         if (!sectorsize)
> -               sectorsize = (u32)sysconf(_SC_PAGESIZE);
> +               sectorsize = (u32)SZ_4K;
>         if (btrfs_check_sectorsize(sectorsize))
>                 goto error;
>
> --
> 2.41.0
>
>

Re: [PATCH v4 0/1] Enforce 4k sectorize by default for mkfs

[Josef Bacik]

On Thu, Nov 16, 2023 at 11:02:23AM -0500, Neal Gompa wrote:
> The Fedora Asahi SIG[0] is working on bringing up support for
> Apple Silicon Macintosh computers through the Fedora Asahi Remix[1].
> 
> Apple Silicon Macs are unusual in that they currently require 16k
> page sizes, which means that the current default for mkfs.btrfs(8)
> makes a filesystem that is unreadable on x86 PCs and most other ARM
> PCs.
> 
> This is now even more of a problem within Apple Silicon Macs as it is now
> possible to nest 4K Fedora Linux VMs on 16K Fedora Asahi Remix machines to
> enable performant x86 emulation[2] and the host storage needs to be compatible
> for both environments.
> 
> Thus, I'd like to see us finally make the switchover to 4k sectorsize
> for new filesystems by default, regardless of page size.
> 
> The initial test run by Hector Martin[3] at request of Qu Wenruo
> looked promising[4], and we've been running with this behavior on
> Fedora Linux since Fedora Linux 36 (at around 6.2) with no issues.
> 

This is a good change and well documented.  This isn't being ignored, it's just
a policy change that we have to be conservative about considering.  We only in
the last 3 months have added a Apple Silicon machine to our testing
infrastructure (running Fedora Asahi fwiw) to make sure we're getting consistent
subpage-blocksize testing.  Generally speaking it's been fine, we've fixed a few
things and haven't broken anything, but it's still comes with some risks when
compared to the default of using the pagesize.

We will continue to discuss this amongst ourselves and figure out what we think
would be a reasonable timeframe to make this switch and let you know what we're
thinking ASAP.  Thanks,

Josef

Re: [PATCH v4 0/1] Enforce 4k sectorize by default for mkfs

[Hector Martin]

On 2023/11/28 1:07, Josef Bacik wrote:
> On Thu, Nov 16, 2023 at 11:02:23AM -0500, Neal Gompa wrote:
>> The Fedora Asahi SIG[0] is working on bringing up support for
>> Apple Silicon Macintosh computers through the Fedora Asahi Remix[1].
>>
>> Apple Silicon Macs are unusual in that they currently require 16k
>> page sizes, which means that the current default for mkfs.btrfs(8)
>> makes a filesystem that is unreadable on x86 PCs and most other ARM
>> PCs.
>>
>> This is now even more of a problem within Apple Silicon Macs as it is now
>> possible to nest 4K Fedora Linux VMs on 16K Fedora Asahi Remix machines to
>> enable performant x86 emulation[2] and the host storage needs to be compatible
>> for both environments.
>>
>> Thus, I'd like to see us finally make the switchover to 4k sectorsize
>> for new filesystems by default, regardless of page size.
>>
>> The initial test run by Hector Martin[3] at request of Qu Wenruo
>> looked promising[4], and we've been running with this behavior on
>> Fedora Linux since Fedora Linux 36 (at around 6.2) with no issues.
>>
> 
> This is a good change and well documented.  This isn't being ignored, it's just
> a policy change that we have to be conservative about considering.  We only in
> the last 3 months have added a Apple Silicon machine to our testing
> infrastructure (running Fedora Asahi fwiw) to make sure we're getting consistent
> subpage-blocksize testing.  Generally speaking it's been fine, we've fixed a few
> things and haven't broken anything, but it's still comes with some risks when
> compared to the default of using the pagesize.
> 
> We will continue to discuss this amongst ourselves and figure out what we think
> would be a reasonable timeframe to make this switch and let you know what we're
> thinking ASAP.  Thanks,

Reminder that the Raspberry Pi 5 is also shipping with 16K pages by
default now. The clock is ticking for an ever-growing stream of people
upset that they can't mount/data-rescue/etc their rPi5 NAS disks from an
x86 machine ;)

- Hector

Re: [PATCH v4 0/1] Enforce 4k sectorize by default for mkfs

[Qu Wenruo]

On 2023/11/29 01:31, Hector Martin wrote:
> 
> 
> On 2023/11/28 1:07, Josef Bacik wrote:
>> On Thu, Nov 16, 2023 at 11:02:23AM -0500, Neal Gompa wrote:
>>> The Fedora Asahi SIG[0] is working on bringing up support for
>>> Apple Silicon Macintosh computers through the Fedora Asahi Remix[1].
>>>
>>> Apple Silicon Macs are unusual in that they currently require 16k
>>> page sizes, which means that the current default for mkfs.btrfs(8)
>>> makes a filesystem that is unreadable on x86 PCs and most other ARM
>>> PCs.
>>>
>>> This is now even more of a problem within Apple Silicon Macs as it is now
>>> possible to nest 4K Fedora Linux VMs on 16K Fedora Asahi Remix machines to
>>> enable performant x86 emulation[2] and the host storage needs to be compatible
>>> for both environments.
>>>
>>> Thus, I'd like to see us finally make the switchover to 4k sectorsize
>>> for new filesystems by default, regardless of page size.
>>>
>>> The initial test run by Hector Martin[3] at request of Qu Wenruo
>>> looked promising[4], and we've been running with this behavior on
>>> Fedora Linux since Fedora Linux 36 (at around 6.2) with no issues.
>>>
>>
>> This is a good change and well documented.  This isn't being ignored, it's just
>> a policy change that we have to be conservative about considering.  We only in
>> the last 3 months have added a Apple Silicon machine to our testing
>> infrastructure (running Fedora Asahi fwiw) to make sure we're getting consistent
>> subpage-blocksize testing.  Generally speaking it's been fine, we've fixed a few
>> things and haven't broken anything, but it's still comes with some risks when
>> compared to the default of using the pagesize.
>>
>> We will continue to discuss this amongst ourselves and figure out what we think
>> would be a reasonable timeframe to make this switch and let you know what we're
>> thinking ASAP.  Thanks,
> 
> Reminder that the Raspberry Pi 5 is also shipping with 16K pages by
> default now. The clock is ticking for an ever-growing stream of people
> upset that they can't mount/data-rescue/etc their rPi5 NAS disks from an
> x86 machine ;)

As long as they are using 5.15+ kernel, they should be able to mount and 
use their RPI NAS with disks from x86 machines.

The change is only for the default mkfs options.

Thanks,
Qu
> 
> - Hector

Re: [PATCH v4 0/1] Enforce 4k sectorize by default for mkfs

[Roman Mamedov]

On Wed, 29 Nov 2023 06:27:26 +1030
Qu Wenruo <wqu@suse.com> wrote:

> > Reminder that the Raspberry Pi 5 is also shipping with 16K pages by
> > default now. The clock is ticking for an ever-growing stream of people
> > upset that they can't mount/data-rescue/etc their rPi5 NAS disks from an
> > x86 machine ;)
> 
> As long as they are using 5.15+ kernel, they should be able to mount and 
> use their RPI NAS with disks from x86 machines.

Doesn't the subpage sectorsize featureset only support sectors less than page
size, not the other way round?

"mkfs.btrfs -s 16K" fails to mount on 6.1.62:

[1077897.120376] BTRFS error (device dm-22): sectorsize 16384 not yet supported for page size 4096
[1077897.120624] BTRFS error (device dm-22): superblock contains fatal errors
[1077897.121394] BTRFS error (device dm-22): open_ctree failed

-- 
With respect,
Roman

Re: [PATCH v4 0/1] Enforce 4k sectorize by default for mkfs

[Qu Wenruo]

On 2023/11/29 06:39, Roman Mamedov wrote:
> On Wed, 29 Nov 2023 06:27:26 +1030
> Qu Wenruo <wqu@suse.com> wrote:
>
>>> Reminder that the Raspberry Pi 5 is also shipping with 16K pages by
>>> default now. The clock is ticking for an ever-growing stream of people
>>> upset that they can't mount/data-rescue/etc their rPi5 NAS disks from an
>>> x86 machine ;)
>>
>> As long as they are using 5.15+ kernel, they should be able to mount and
>> use their RPI NAS with disks from x86 machines.
>
> Doesn't the subpage sectorsize featureset only support sectors less than page
> size, not the other way round?

Well, if using the existing disks, it's really more common to let 16K
page size systems to mount 4K sector systems.

>
> "mkfs.btrfs -s 16K" fails to mount on 6.1.62:
>
> [1077897.120376] BTRFS error (device dm-22): sectorsize 16384 not yet supported for page size 4096
> [1077897.120624] BTRFS error (device dm-22): superblock contains fatal errors
> [1077897.121394] BTRFS error (device dm-22): open_ctree failed
>

That's always the case.

Although with the recent folio changes, we may add support for
multi-page sectorsizes in the future.

Thanks,
Qu

Re: [PATCH v4 0/1] Enforce 4k sectorize by default for mkfs

[Neal Gompa]

On Tue, Nov 28, 2023 at 2:57 PM Qu Wenruo <wqu@suse.com> wrote:
>
>
>
> On 2023/11/29 01:31, Hector Martin wrote:
> >
> >
> > On 2023/11/28 1:07, Josef Bacik wrote:
> >> On Thu, Nov 16, 2023 at 11:02:23AM -0500, Neal Gompa wrote:
> >>> The Fedora Asahi SIG[0] is working on bringing up support for
> >>> Apple Silicon Macintosh computers through the Fedora Asahi Remix[1].
> >>>
> >>> Apple Silicon Macs are unusual in that they currently require 16k
> >>> page sizes, which means that the current default for mkfs.btrfs(8)
> >>> makes a filesystem that is unreadable on x86 PCs and most other ARM
> >>> PCs.
> >>>
> >>> This is now even more of a problem within Apple Silicon Macs as it is now
> >>> possible to nest 4K Fedora Linux VMs on 16K Fedora Asahi Remix machines to
> >>> enable performant x86 emulation[2] and the host storage needs to be compatible
> >>> for both environments.
> >>>
> >>> Thus, I'd like to see us finally make the switchover to 4k sectorsize
> >>> for new filesystems by default, regardless of page size.
> >>>
> >>> The initial test run by Hector Martin[3] at request of Qu Wenruo
> >>> looked promising[4], and we've been running with this behavior on
> >>> Fedora Linux since Fedora Linux 36 (at around 6.2) with no issues.
> >>>
> >>
> >> This is a good change and well documented.  This isn't being ignored, it's just
> >> a policy change that we have to be conservative about considering.  We only in
> >> the last 3 months have added a Apple Silicon machine to our testing
> >> infrastructure (running Fedora Asahi fwiw) to make sure we're getting consistent
> >> subpage-blocksize testing.  Generally speaking it's been fine, we've fixed a few
> >> things and haven't broken anything, but it's still comes with some risks when
> >> compared to the default of using the pagesize.
> >>
> >> We will continue to discuss this amongst ourselves and figure out what we think
> >> would be a reasonable timeframe to make this switch and let you know what we're
> >> thinking ASAP.  Thanks,
> >
> > Reminder that the Raspberry Pi 5 is also shipping with 16K pages by
> > default now. The clock is ticking for an ever-growing stream of people
> > upset that they can't mount/data-rescue/etc their rPi5 NAS disks from an
> > x86 machine ;)
>
> As long as they are using 5.15+ kernel, they should be able to mount and
> use their RPI NAS with disks from x86 machines.
>
> The change is only for the default mkfs options.
>

Right, and the thing is, it's fairly common for the disks to be
formatted from a Raspberry Pi. So until some kind of support for using
any sector size on any architecture regardless of page size lands,
this is going to be a big problem.



-- 
真実はいつも一つ！/ Always, there's only one truth!

Re: [PATCH v4 0/1] Enforce 4k sectorize by default for mkfs

[Hector Martin]

On 2023/11/29 6:24, Neal Gompa wrote:
> On Tue, Nov 28, 2023 at 2:57 PM Qu Wenruo <wqu@suse.com> wrote:
>>
>>
>>
>> On 2023/11/29 01:31, Hector Martin wrote:
>>>
>>>
>>> On 2023/11/28 1:07, Josef Bacik wrote:
>>>> On Thu, Nov 16, 2023 at 11:02:23AM -0500, Neal Gompa wrote:
>>>>> The Fedora Asahi SIG[0] is working on bringing up support for
>>>>> Apple Silicon Macintosh computers through the Fedora Asahi Remix[1].
>>>>>
>>>>> Apple Silicon Macs are unusual in that they currently require 16k
>>>>> page sizes, which means that the current default for mkfs.btrfs(8)
>>>>> makes a filesystem that is unreadable on x86 PCs and most other ARM
>>>>> PCs.
>>>>>
>>>>> This is now even more of a problem within Apple Silicon Macs as it is now
>>>>> possible to nest 4K Fedora Linux VMs on 16K Fedora Asahi Remix machines to
>>>>> enable performant x86 emulation[2] and the host storage needs to be compatible
>>>>> for both environments.
>>>>>
>>>>> Thus, I'd like to see us finally make the switchover to 4k sectorsize
>>>>> for new filesystems by default, regardless of page size.
>>>>>
>>>>> The initial test run by Hector Martin[3] at request of Qu Wenruo
>>>>> looked promising[4], and we've been running with this behavior on
>>>>> Fedora Linux since Fedora Linux 36 (at around 6.2) with no issues.
>>>>>
>>>>
>>>> This is a good change and well documented.  This isn't being ignored, it's just
>>>> a policy change that we have to be conservative about considering.  We only in
>>>> the last 3 months have added a Apple Silicon machine to our testing
>>>> infrastructure (running Fedora Asahi fwiw) to make sure we're getting consistent
>>>> subpage-blocksize testing.  Generally speaking it's been fine, we've fixed a few
>>>> things and haven't broken anything, but it's still comes with some risks when
>>>> compared to the default of using the pagesize.
>>>>
>>>> We will continue to discuss this amongst ourselves and figure out what we think
>>>> would be a reasonable timeframe to make this switch and let you know what we're
>>>> thinking ASAP.  Thanks,
>>>
>>> Reminder that the Raspberry Pi 5 is also shipping with 16K pages by
>>> default now. The clock is ticking for an ever-growing stream of people
>>> upset that they can't mount/data-rescue/etc their rPi5 NAS disks from an
>>> x86 machine ;)
>>
>> As long as they are using 5.15+ kernel, they should be able to mount and
>> use their RPI NAS with disks from x86 machines.
>>
>> The change is only for the default mkfs options.
>>
> 
> Right, and the thing is, it's fairly common for the disks to be
> formatted from a Raspberry Pi. So until some kind of support for using
> any sector size on any architecture regardless of page size lands,
> this is going to be a big problem.
> 

Yup, I meant what I said.

Someone sets up a rPi5 as a NAS, formats the disk from it, as you would
normally when setting up such a thing from scratch. Later, the rPi stops
working, as rPis often do. This person's data is now *completely
inaccessible* until they find another Raspberry Pi 5 or an Apple Silicon
laptop.

This is going to be *common*. And since the 16K decision is made at
format time, these people are going to be oblivious until they find
themselves with an urgent need to acquire a Raspberry Pi 5 to access
their data at all, and then they're going to be mad. So the longer you
wait to flip the switch, the more people unaware of their own data's
fragile accessibility condition you will build up, and the more upset
people you're going to have even long after the change was finally made.

- Hector

Re: [PATCH v4 0/1] Enforce 4k sectorize by default for mkfs

[Qu Wenruo]

On 2023/11/29 23:28, Hector Martin wrote:
>
>
> On 2023/11/29 6:24, Neal Gompa wrote:
>> On Tue, Nov 28, 2023 at 2:57 PM Qu Wenruo <wqu@suse.com> wrote:
>>>
>>>
>>>
>>> On 2023/11/29 01:31, Hector Martin wrote:
>>>>
>>>>
>>>> On 2023/11/28 1:07, Josef Bacik wrote:
>>>>> On Thu, Nov 16, 2023 at 11:02:23AM -0500, Neal Gompa wrote:
>>>>>> The Fedora Asahi SIG[0] is working on bringing up support for
>>>>>> Apple Silicon Macintosh computers through the Fedora Asahi Remix[1].
>>>>>>
>>>>>> Apple Silicon Macs are unusual in that they currently require 16k
>>>>>> page sizes, which means that the current default for mkfs.btrfs(8)
>>>>>> makes a filesystem that is unreadable on x86 PCs and most other ARM
>>>>>> PCs.
>>>>>>
>>>>>> This is now even more of a problem within Apple Silicon Macs as it is now
>>>>>> possible to nest 4K Fedora Linux VMs on 16K Fedora Asahi Remix machines to
>>>>>> enable performant x86 emulation[2] and the host storage needs to be compatible
>>>>>> for both environments.
>>>>>>
>>>>>> Thus, I'd like to see us finally make the switchover to 4k sectorsize
>>>>>> for new filesystems by default, regardless of page size.
>>>>>>
>>>>>> The initial test run by Hector Martin[3] at request of Qu Wenruo
>>>>>> looked promising[4], and we've been running with this behavior on
>>>>>> Fedora Linux since Fedora Linux 36 (at around 6.2) with no issues.
>>>>>>
>>>>>
>>>>> This is a good change and well documented.  This isn't being ignored, it's just
>>>>> a policy change that we have to be conservative about considering.  We only in
>>>>> the last 3 months have added a Apple Silicon machine to our testing
>>>>> infrastructure (running Fedora Asahi fwiw) to make sure we're getting consistent
>>>>> subpage-blocksize testing.  Generally speaking it's been fine, we've fixed a few
>>>>> things and haven't broken anything, but it's still comes with some risks when
>>>>> compared to the default of using the pagesize.
>>>>>
>>>>> We will continue to discuss this amongst ourselves and figure out what we think
>>>>> would be a reasonable timeframe to make this switch and let you know what we're
>>>>> thinking ASAP.  Thanks,
>>>>
>>>> Reminder that the Raspberry Pi 5 is also shipping with 16K pages by
>>>> default now. The clock is ticking for an ever-growing stream of people
>>>> upset that they can't mount/data-rescue/etc their rPi5 NAS disks from an
>>>> x86 machine ;)
>>>
>>> As long as they are using 5.15+ kernel, they should be able to mount and
>>> use their RPI NAS with disks from x86 machines.
>>>
>>> The change is only for the default mkfs options.
>>>
>>
>> Right, and the thing is, it's fairly common for the disks to be
>> formatted from a Raspberry Pi. So until some kind of support for using
>> any sector size on any architecture regardless of page size lands,
>> this is going to be a big problem.
>>
>
> Yup, I meant what I said.
>
> Someone sets up a rPi5 as a NAS, formats the disk from it, as you would
> normally when setting up such a thing from scratch. Later, the rPi stops
> working, as rPis often do. This person's data is now *completely
> inaccessible* until they find another Raspberry Pi 5 or an Apple Silicon
> laptop.
Got it.

I am putting too much trust on RPI, as my experience is pretty good so
far (just for VM hosting and running fstests), thus I though everyone
would just go x86->aarch64, at least for NAS hosting/VM testing...

>
> This is going to be *common*. And since the 16K decision is made at
> format time, these people are going to be oblivious until they find
> themselves with an urgent need to acquire a Raspberry Pi 5 to access
> their data at all, and then they're going to be mad. So the longer you
> wait to flip the switch, the more people unaware of their own data's
> fragile accessibility condition you will build up, and the more upset
> people you're going to have even long after the change was finally made.

In that case, I'm totally fine to support the switch of default sector
size, sooner than later.

With Asahi already running 4K sector sizes, and I have not received any
death thread for the loss of one's data, I believe the prerequisite for
the switch is already here.

And even if there are hidden bugs, default to 4K is in fact going to
make it faster to get reports and fixed.

Thanks,
Qu
>
> - Hector

Re: [PATCH v4 0/1] Enforce 4k sectorize by default for mkfs

[Neal Gompa]

On Wed, Nov 29, 2023 at 3:28 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>
>
> On 2023/11/29 23:28, Hector Martin wrote:
> >
> >
> > On 2023/11/29 6:24, Neal Gompa wrote:
> >> On Tue, Nov 28, 2023 at 2:57 PM Qu Wenruo <wqu@suse.com> wrote:
> >>>
> >>>
> >>>
> >>> On 2023/11/29 01:31, Hector Martin wrote:
> >>>>
> >>>>
> >>>> On 2023/11/28 1:07, Josef Bacik wrote:
> >>>>> On Thu, Nov 16, 2023 at 11:02:23AM -0500, Neal Gompa wrote:
> >>>>>> The Fedora Asahi SIG[0] is working on bringing up support for
> >>>>>> Apple Silicon Macintosh computers through the Fedora Asahi Remix[1].
> >>>>>>
> >>>>>> Apple Silicon Macs are unusual in that they currently require 16k
> >>>>>> page sizes, which means that the current default for mkfs.btrfs(8)
> >>>>>> makes a filesystem that is unreadable on x86 PCs and most other ARM
> >>>>>> PCs.
> >>>>>>
> >>>>>> This is now even more of a problem within Apple Silicon Macs as it is now
> >>>>>> possible to nest 4K Fedora Linux VMs on 16K Fedora Asahi Remix machines to
> >>>>>> enable performant x86 emulation[2] and the host storage needs to be compatible
> >>>>>> for both environments.
> >>>>>>
> >>>>>> Thus, I'd like to see us finally make the switchover to 4k sectorsize
> >>>>>> for new filesystems by default, regardless of page size.
> >>>>>>
> >>>>>> The initial test run by Hector Martin[3] at request of Qu Wenruo
> >>>>>> looked promising[4], and we've been running with this behavior on
> >>>>>> Fedora Linux since Fedora Linux 36 (at around 6.2) with no issues.
> >>>>>>
> >>>>>
> >>>>> This is a good change and well documented.  This isn't being ignored, it's just
> >>>>> a policy change that we have to be conservative about considering.  We only in
> >>>>> the last 3 months have added a Apple Silicon machine to our testing
> >>>>> infrastructure (running Fedora Asahi fwiw) to make sure we're getting consistent
> >>>>> subpage-blocksize testing.  Generally speaking it's been fine, we've fixed a few
> >>>>> things and haven't broken anything, but it's still comes with some risks when
> >>>>> compared to the default of using the pagesize.
> >>>>>
> >>>>> We will continue to discuss this amongst ourselves and figure out what we think
> >>>>> would be a reasonable timeframe to make this switch and let you know what we're
> >>>>> thinking ASAP.  Thanks,
> >>>>
> >>>> Reminder that the Raspberry Pi 5 is also shipping with 16K pages by
> >>>> default now. The clock is ticking for an ever-growing stream of people
> >>>> upset that they can't mount/data-rescue/etc their rPi5 NAS disks from an
> >>>> x86 machine ;)
> >>>
> >>> As long as they are using 5.15+ kernel, they should be able to mount and
> >>> use their RPI NAS with disks from x86 machines.
> >>>
> >>> The change is only for the default mkfs options.
> >>>
> >>
> >> Right, and the thing is, it's fairly common for the disks to be
> >> formatted from a Raspberry Pi. So until some kind of support for using
> >> any sector size on any architecture regardless of page size lands,
> >> this is going to be a big problem.
> >>
> >
> > Yup, I meant what I said.
> >
> > Someone sets up a rPi5 as a NAS, formats the disk from it, as you would
> > normally when setting up such a thing from scratch. Later, the rPi stops
> > working, as rPis often do. This person's data is now *completely
> > inaccessible* until they find another Raspberry Pi 5 or an Apple Silicon
> > laptop.
> Got it.
>
> I am putting too much trust on RPI, as my experience is pretty good so
> far (just for VM hosting and running fstests), thus I though everyone
> would just go x86->aarch64, at least for NAS hosting/VM testing...
>
> >
> > This is going to be *common*. And since the 16K decision is made at
> > format time, these people are going to be oblivious until they find
> > themselves with an urgent need to acquire a Raspberry Pi 5 to access
> > their data at all, and then they're going to be mad. So the longer you
> > wait to flip the switch, the more people unaware of their own data's
> > fragile accessibility condition you will build up, and the more upset
> > people you're going to have even long after the change was finally made.
>
> In that case, I'm totally fine to support the switch of default sector
> size, sooner than later.
>
> With Asahi already running 4K sector sizes, and I have not received any
> death thread for the loss of one's data, I believe the prerequisite for
> the switch is already here.
>
> And even if there are hidden bugs, default to 4K is in fact going to
> make it faster to get reports and fixed.
>

For what it's worth, this change was applied at the Fedora level, so
*all* architectures have been using 4k sectorize by default for some
time now, including Fedora Asahi (ARM 16k) and Fedora POWER (64k).


-- 
真実はいつも一つ！/ Always, there's only one truth!

Re: [PATCH v4 0/1] Enforce 4k sectorize by default for mkfs

[David Sterba]

On Thu, Nov 16, 2023 at 11:02:23AM -0500, Neal Gompa wrote:
> The Fedora Asahi SIG[0] is working on bringing up support for
> Apple Silicon Macintosh computers through the Fedora Asahi Remix[1].
> 
> Apple Silicon Macs are unusual in that they currently require 16k
> page sizes, which means that the current default for mkfs.btrfs(8)
> makes a filesystem that is unreadable on x86 PCs and most other ARM
> PCs.
> 
> This is now even more of a problem within Apple Silicon Macs as it is now
> possible to nest 4K Fedora Linux VMs on 16K Fedora Asahi Remix machines to
> enable performant x86 emulation[2] and the host storage needs to be compatible
> for both environments.
> 
> Thus, I'd like to see us finally make the switchover to 4k sectorsize
> for new filesystems by default, regardless of page size.
> 
> The initial test run by Hector Martin[3] at request of Qu Wenruo
> looked promising[4], and we've been running with this behavior on
> Fedora Linux since Fedora Linux 36 (at around 6.2) with no issues.
> 
> === Changelog ===
> 
> v4: Fixed minor errors in the cover letter and patch subject
> 
> v3: Refreshed cover letter, rebased to latest, updated doc references for v6.7
> 
> v2: Rebased to latest, updated doc references for v6.6
> 
> Final v1: Collected Reviewed-by tags for inclusion.
> 
> RFC v2: Addressed documentation feedback
> 
> RFC v1: Initial submission
> 
> [0]: https://fedoraproject.org/wiki/SIGs/Asahi
> [1]: https://fedora-asahi-remix.org/
> [2]: https://sinrega.org/2023-10-06-using-microvms-for-gaming-on-fedora-asahi/
> [3]: https://lore.kernel.org/linux-btrfs/fdffeecd-964f-0c69-f869-eb9ceca20263@suse.com/T/#m11d7939de96c43b3a7cdabc7c568d8bcafc7ca83
> [4]: https://lore.kernel.org/linux-btrfs/fdffeecd-964f-0c69-f869-eb9ceca20263@suse.com/T/#mf382b78a8122b0cb82147a536c85b6a9098a2895
> 
> Neal Gompa (1):
>   btrfs-progs: mkfs: Enforce 4k sectorsize by default

FYI, current plan is to add the change to 6.7 release with ETA in
January. We've discussed this and given the increasing demand for that
from various distros and testing coverage so done far it seems that it's
sufficient.

Re: [PATCH v4 0/1] Enforce 4k sectorize by default for mkfs

[Neal Gompa]

On Wed, Dec 13, 2023 at 5:32 PM David Sterba <dsterba@suse.cz> wrote:
>
> On Thu, Nov 16, 2023 at 11:02:23AM -0500, Neal Gompa wrote:
> > The Fedora Asahi SIG[0] is working on bringing up support for
> > Apple Silicon Macintosh computers through the Fedora Asahi Remix[1].
> >
> > Apple Silicon Macs are unusual in that they currently require 16k
> > page sizes, which means that the current default for mkfs.btrfs(8)
> > makes a filesystem that is unreadable on x86 PCs and most other ARM
> > PCs.
> >
> > This is now even more of a problem within Apple Silicon Macs as it is now
> > possible to nest 4K Fedora Linux VMs on 16K Fedora Asahi Remix machines to
> > enable performant x86 emulation[2] and the host storage needs to be compatible
> > for both environments.
> >
> > Thus, I'd like to see us finally make the switchover to 4k sectorsize
> > for new filesystems by default, regardless of page size.
> >
> > The initial test run by Hector Martin[3] at request of Qu Wenruo
> > looked promising[4], and we've been running with this behavior on
> > Fedora Linux since Fedora Linux 36 (at around 6.2) with no issues.
> >
> > === Changelog ===
> >
> > v4: Fixed minor errors in the cover letter and patch subject
> >
> > v3: Refreshed cover letter, rebased to latest, updated doc references for v6.7
> >
> > v2: Rebased to latest, updated doc references for v6.6
> >
> > Final v1: Collected Reviewed-by tags for inclusion.
> >
> > RFC v2: Addressed documentation feedback
> >
> > RFC v1: Initial submission
> >
> > [0]: https://fedoraproject.org/wiki/SIGs/Asahi
> > [1]: https://fedora-asahi-remix.org/
> > [2]: https://sinrega.org/2023-10-06-using-microvms-for-gaming-on-fedora-asahi/
> > [3]: https://lore.kernel.org/linux-btrfs/fdffeecd-964f-0c69-f869-eb9ceca20263@suse.com/T/#m11d7939de96c43b3a7cdabc7c568d8bcafc7ca83
> > [4]: https://lore.kernel.org/linux-btrfs/fdffeecd-964f-0c69-f869-eb9ceca20263@suse.com/T/#mf382b78a8122b0cb82147a536c85b6a9098a2895
> >
> > Neal Gompa (1):
> >   btrfs-progs: mkfs: Enforce 4k sectorsize by default
>
> FYI, current plan is to add the change to 6.7 release with ETA in
> January. We've discussed this and given the increasing demand for that
> from various distros and testing coverage so done far it seems that it's
> sufficient.
>

Is this queued yet for the btrfs-progs v6.7 release? I don't see it in
your devel tree[1] yet...

[1]: https://github.com/kdave/btrfs-progs/commits/devel/


-- 
真実はいつも一つ！/ Always, there's only one truth!