> On 15 Sep 2016, at 15:49, Andreas Färber <[email protected]> wrote: > > Hi Alex, > > Am 15.09.2016 um 13:47 schrieb Alexander Graf: >> [...] because we have people who have Leap 42.1 and current Tumbleweed >> installed, we can’t just switch from 64k to 4k PAGE_SIZE, because our friend >> btrfs embeds the page size into its on-disk format and can only read it when >> they’re identical. So switching would break existing btrfs installations. >> >> There hasn’t been any well working solution to make btrfs more compatible, >> we don’t really want 42.2 to diverge from its origins and 4k gets us running >> on smaller systems which are starting to pop up more and more in the 64bit >> world. Given all that, is anyone seriously opposed to switching everything >> to 4k? > > I am opposed for Tumbleweed. > > And I already expressed deep concerns about 42.2 despite not affected > myself: In particular I find it very troubling that some people > including Ludwig himself are now in hindsight degrading our stable 42.1 > release to some experimental thing that supposedly no one has installed > or cares about - then we don't need a 42.2 release either and could > focus our efforts on Tumbleweed instead!
I don’t think anyone in this group degraded the stability of 42.1. But if I get the chance of breaking a small user base and instead have the overall product work again and be consistent, I can’t shake off the feeling that breaking is the better option. > >> We could have a patch like the one below in the kernel pre-install script, >> preventing people from breaking their systems, add notes on the wiki, maybe >> ask SoftIron to send emails to people who bought systems with >> Tumbleweed/42.1 preinstalled and then close that horrible chapter forever. > > Note that your patch does not address the 42.2 installer, whose kernel > and initrd to not get installed by rpm. It does, because the 42.2 installer wouldn’t be able to mount the btrfs volume. > I would be okay for Tumbleweed iff instead of that horrible blocker > patch we could get a patch for, e.g., dracut to convert the volume from > 64k to 4k on boot if necessary, keeping zypper dup working that way. Is > there no FUSE implementation or some btrfs(8) subcommand to change the > blocksize without having to mount it in the kernel? Unfortunately it’s not easy to pull off :(. > Also, didn't you suggest using a KMP with patched btrfs module, to > abstract the page size? I thought that was your designated solution for > at least Tumbleweed. Yes, and nobody wants to actively support it, pushing us into an even worse corner where we’d end up with lots of ARM special cases that nobody else wants to look at. It means more work on our shoulders that we can’t cope with. > For Tumbleweed I think it's reasonable to expect people to do a zypper > dup instead of .iso upgrade. > > (No, there are not JeOS images for every platform, and even if there > were, not everyone wants to loose all their data and the currently well > working upgrade path.) Again, the iso upgrade path doesn’t work because the installations system would be 4k based. > How does GRUB2 deal with btrfs page size? Does it need to get > reinstalled after switching kernel page size or does it use a "better" > driver implementation than the kernel? IIUC it just works - we’re using it with both 4k and 64k systems today. > Any other userspace packages that may require a rebuild if changed? Nope. Alex -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
