On 15 September 2016 at 13:47, Alexander Graf <[email protected]> wrote: > Hello fellow openSUSE ARM developers, > > As you might have realized, we haven’t published openSUSE Tumbleweed in quite > some time. The biggest reason for that (among minor hickups) is that we’re > using btrfs on 64k PAGE_SIZE, which started to have massive disk space > requirements (1GB of data doesn’t fit in an 8GB partition). > > We also in between benchmarked 64k vs 4k intensively and concluded that 4k > PAGE_SIZE is the much better option, so we’re at 4k with the Leap 42.2 > backing kernel tree. > > However, 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? 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. >
I am all for switching to 4k. Yes we will certainly inconvenience some users, but as long as we communicate what is happening and why I see no reason for any genuine complaints. One of the big reasons for Leap is to close the gap between openSUSE and SLE; by continuing with having a separate page size we are increasing the maintenance burden on the kernel team as well as diverging from the goals of the distro. Regardless of the complications that switching page size brings, technically 64k is the wrong choice for general purpose compute. It actually hinders things and degrades performance with zero gain. We will be doing hardware vendors that ship openSUSE a favour by switching. Regards, Andy > Keep in mind that non-btrfs and 32bit installations are completely untouched > by any of this. > > I’m sure we would lose one or two users, but I’d rather have that than spend > more time not publishing images and keeping us from doing a future-looking > 42.2 release which would drive us into a corner that makes us lose even more. > > For reference, there’s a bugzilla about this atm as well: > http://bugzilla.opensuse.org/show_bug.cgi?id=998663 > > > Alex > > > > diff --git a/rpm/pre.sh b/rpm/pre.sh > index f02d9c0..347b0d4 100644 > --- a/rpm/pre.sh > +++ b/rpm/pre.sh > @@ -19,3 +19,22 @@ if [ @BASE_PACKAGE@ = 1 -a "$YAST_IS_RUNNING" != "" ]; then > fi > fi > fi > + > +# On AArch64 we switched from 64k PAGE_SIZE to 4k PAGE_SIZE. Unfortunately > +# btrfs can only use file systems created with the same PAGE_SIZE. So we > +# check if the user has any btrfs file systems mounted and refuse to install > +# in that case. > +if [ $( uname -m ) = aarch64 -a "$( zgrep CONFIG_ARM64_64K_PAGES=y > /proc/config.gz )" ]; then > + if cut -d ' ' -f 3 /proc/mounts | grep -q btrfs; then > + echo "You are using btrfs on a 64kb PAGE_SIZE kernel. This" > >&2 > + echo "kernel switched to 4kb PAGE_SIZE which will prevent" >&2 > + echo "it from mounting that file system." >&2 > + echo >&2 > + echo "Refusing from installing this kernel, to make sure you" > >&2 > + echo "do not end up with an unusable system. If you want to" > >&2 > + echo "install it, please convert the btrfs file system to a" > >&2 > + echo "different file system." >&2 > + > + exit 1 > + fi > +fi-- > To unsubscribe, e-mail: [email protected] > To contact the owner, e-mail: [email protected] > -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
