On Thu, Jan 7, 2021 at 4:51 AM Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > > On Thu, Jan 7, 2021 at 7:54 AM Daniel Pocock <daniel@xxxxxxxxxx> wrote: > > > > > > > > On 07/01/2021 02:02, Neal Gompa wrote: > > > On Wed, Jan 6, 2021 at 6:27 PM Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > > >> > > >> On Wed, Jan 6, 2021 at 11:25 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > >>> > > >>> On Wed, Jan 6, 2021 at 6:03 PM Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > > >>>> > > >>>>> Regardless of the packages above, I still think the Btrfs issue is the > > >>>>> biggest surprise for people and it is worse because it is the default > > >>>>> filesystem now. People can reboot into a new kernel but they may not be > > >>>>> able to easily reformat their disks after mkfs at 64k. > > >>>> > > >>>> What's the situation on filesystems like xfs or ext4? > > >>> > > >>> This issue was mostly resolved for both filesystems years ago. There > > >>> is a patchset in review in linux-btrfs@ mailing list that resolves > > >>> this problem. I expect that it'll land in Linux 5.11 or 5.12, though Josef may > > >>> know more exact details on timelines. > > >> > > >> Unless it's a small fix it'll be 5.12+ now given the main merge window > > >> for 5.11 is closed. > > > > > > Then yeah, we're probably looking at 5.12, since it's ~80 patches last > > > I checked. > > > > This will be good for the workstation installed with the latest Fedora > > if it can use the volumes formatted with 4k and create them that way by > > default. > > I suspect that's for the btrfs tools and their maintainers to decide. > > > If the user formats a disk such as a USB stick and tries to use it with > > any other GNU/Linux system with an older kernel, such as RHEL, they may > > be surprised. > > TBH that's no different for all sorts of filesystems and feature > enhancements to them, always has been. > > > With the changes mentioned, will it be possible to have 4k as default > > for mkfs.btrfs unless the user manually overrides it? > > I'm sure it's possible, as mentioned above that would be a decision > for the upstream btrfs maintainers, they would be better positioned to > know the impact of such a change. > While I'm not entirely sure, I believe that btrfs-progs will format 4k by default on all arches once everything is done. There's no particularly good reason to keep doing 64k after this is done, since it's somewhat wasteful for storage devices. > > As far as I know, there are no problems using ext4 on ppc64el systems > > but as btrfs is now the default, some people may end up with the 64k > > block size if they do an install today using the current Fedora installer. > > I suspect the amount of people using btrfs on ppc64le and moving those > disks to other architectures are quite limited especially given it was > just introduced as default in F-33, like everything storage related on > any filesystem backups are always recommended. > > > Another hack: maybe the installer can just default to ext4 on this > > architecture until 5.12 is available. > > Well given 5.12 will likely be the shipping kernel for F-34 you've > still got a few weeks to liaise with btrfs upstream to see if > everything is going to be in place (kernel/tools etc) to submit a self > contained change for F-34 to ensure this is resolved to your > satisfaction for that release. > I'm reasonably confident that we're going to have this fixed for Fedora 34. I would not be surprised to see foreign page size read support merged in the coming days, and then the write support merged within the next few weeks. Upstream has made really good progress here and I'm confident in it being fixed in the Linux 5.12 timeframe. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
