XFS is the default file system used by the main Enterprise Linux
distribution, so I think that we should default to use it too.

<Md> juliank: since RH defaults to XFS I think that we should as well, but I
     have no idea about how to do this in Debian without wasting months in
     bikeshedding and then fail anyway :-(
<zeha> start with a partman bug and see if it dissolves into bikeshedding?

Hi,

I don't really have a skin in this game, but I don't think that the fact
that RHEL defaults XFS is really a compelling argument to switch the default
filesystem in Debian.

Unlike RHEL, Debian isn't an enterprise distribution, it's a universal distribution,
so it has quite different needs when it comes to the default choices.

Adrian

Hi,

* John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> [260804 11:37]:

That's certainly a valid point. I take this to mean that you think
we should have technical arguments for one or another default, as
opposed to picking something just because someone else does it.

Inferring from above, what does the "universial distribution" do
here? We've been riding this argument for so long, that we now have
defaults (everywhere in the distro) that are bad for almost
everybody. That's certainly a way of being "universal", but not in a
good way.

IMO the best thing would be for someone to point out technical
tradeoffs of different available choices, and then as a distro we
can make a decision. If we cannot pick anything because we think we
cannot pick anything, then also the default we cannot pick should go
away.

If you have any insights on what the universal distribution needs as
the default, please by all means post them! But otherwise, please
lets stop invoking the universal distro.

Best,
Chris

Hi,

Debian as opposed to RHEL (and SLES) has a much larger set of supported
architectures, configurations and packages. Enterprise distributions are
usually trimmed down to specific usecases such as servers, cloud instances
or workstations.

That's because enterprise distributions are fully supported by their vendors
which is only possible when they restrict their supported flavors to very
specific configurations and architectures.

In Debian, we don't have such restrictions and the same distribution that
can be installed on a POWER system or IBM mainframe can be installed on a
32-bit ARM or RISC-V embedded board or a Chinese LoongArch system.

Since ext2/ext3/ext4 has been the default filesystem for a long time, it has
been battle-tested on a large number of configurations and architectures, so
it's safe to assume it will work fine on any of the systems that are officially
and unofficially supported by Debian. Whether that will apply to XFS, I don't
know.

I'm not saying that XFS may not be a good choice, it certainly is and I'm
using it for certain applications. However, whether it makes sense to use
it as a default for an operating system that is expected to run almost
everywhere, is another question.

Adrian

have seen so many users need to shrink a partition in order to free disk
space for another partition. With XFS their only option would be to
reinstall and/or back up and restore.

Also ISTR that XFS is more memory-hungry than ext4, and read about some
operations which caused transient high memory usage. But maybe this is
not relevant any more with current memory sizes ?

Maybe the default filesystem could be made conditional to the
architecture, memory size, partition size... ?

Note: the default filesystem type can be preseeded.

IIRC, *SUSE used to default the / filesystem to EXT4, and /home/ to XFS. That's
been switched to BTRFS for both / and /home/. I think Fedora may also have
switched to BTRFS.

...er, Some of us do not like the boiler-plate defaults carried over by
the (lazy ?) hosting providers when they provision a bare metal and/or
virtualized/cloud servers instance(s).

Reiser4, likewise, cannot be shrunk. Yet, I have made it the default
file system in my later customized d-i, i.e., partman-base hack:
< https://metztli.it/trixie/partman-base_reiser4-default.png >

And, previously, I did override the Debian default ext/x/y file system
in provisioned servers by uploading my custom reiser4 image -- either to
be used in virtual CD/DVD ROM device and/or booting from the d-i image
residing in either of a two (at least) disk storage media in bare metal
instances, and repartitioning/reinstalling Debian on reiser4:
< https://metztli.blog/nochtli/boot-metztli-reiser4-netboot-on >

And whether user selected d-i Expert Installation option [?] then XFS
should be the default. After all, users who subsequently resize their
partitions likely are novices who have not planned their partitioning
and likely would not appreciate XFS/Reiser4, either.

That would make sense, yes.

Right. It's mostly meaningless at this level.

I don't think so. There is really a huge difference between what you can do
with Debian as compared to what you can do with RHEL or SLES.

Try setting up a cross-compiler environment or try reading any filesystem
that isn't mainstream such as HFS/HFS+ or install some obscure package for
medical sciences.

We shouldn't really diminish the value that comes with Debian's universal
usefulness. Of course, if your use case is installing Linux on a standard
x86_64 laptop for internet browsing, you might not see that flexibility,
but that doesn't mean it doesn't exist.

Adrian

The "universal" here gives no guidance at all on a default filesystem
for installation, which is the question here. Any of the systems we
support should be able to work well with any of the options we might
consider here.

Not everything has to be a special snowflake on every axis here.

Yes, should be. That doesn't mean that's it's automatically going to be
the case. For ext2/3/4, we know for sure it will work well on any system
Debian supports. For XFS, that's not so sure.

That's got nothing to do with being a snowflake. Different distributions have
different usecases and that's okay. FWIW, SLES/openSUSE doesn't use XFS but
BtrFS by default. So, why not default to BtrFS then but XFS?

Adrian

Indeed, why not?

I think your HFS/HFS+ argument is a strawman. Correct me if I'm
wrong. But we also wouldn't consider FAT16, for probably the same
reasons (which I think are: foregin FS, severe feature
limitation, ...).

ext4, XFS, BtrFS are "native" filesystems, actively maintained. ZFS
is likely out due to the licensing (and thus not-builtin) reasons.

Evaluating the three options seems good? I don't have a current
overview of which hardware we actually try to support and what the
requirements and stability of the mentioned filesystems are.
But then I also don't mind staying on ext4. If there are good
reasons for XFS or BtrFS, please by all means change the default.

Chris

I disagree. Expert install is intended to ask more questions, not change
defaults. Or did you mean manual partitioning ?
But I often have to tell such users to use expert install in order to
see some low-priority question.

AFAIK openSUSE uses btrfs for subvolumes and snapshots. partman-btrfs
support of subvolumes is still limited to a single @rootfs subvolume.

Hi,

Felix Miata <mrmazda@earthlink.net> writes:
Fedora *server* defaults to XFS.  SUSE Linux Enterprise Desktop defaults
to btrfs.  SUSE Linux Enterprise Server puts the rootfs on btrfs, but
uses XFS for data partitions.

If we're going to use a future-directed metric for "what users want",
btrfs-progs popcon looks like it will overtake xfsprogs by the time Duke
is released.  P.S. I still want to form a btrfs-enablement team, so
please let me know if you're interested!

Some other factors that might be worth noting: XFS does not appear to
ever be considered for use on small systems like phones, firewalls, etc.
XFS also used to be more fragile than ext4 in cases of kernel panic,
sudden loss of power, etc, and as far as I know this is still the case.
Should we really make the default fs one that is designed for systems
that have redundant PSUs and UPSs?  That doesn't sound very "do no harm"
to me, and in the same vein, there are workloads that trigger consumer
SSD-destroying write amplification with btrfs; this is why I'm not
pushing for btrfs-by-default at this time.

One of our DDs is also significantly involved with ext4, but to the best
of my knowledge we don't have anyone who also works on upstream XFS.
I remember reading an argument about how this is an advantage when
upstream has breaking changes that need to be disentangled from bugfixes
targeting the LTS kernel that we follow.

Cheers,
Nicholas

Does xfs_repair still require potentially crazy amounts of ram for
larger drives?  After all is it unreasonable for someone to have a 4TB
drive in a system with 8GB ram these days?  My understanding is xfs_repair
can't deal with that.  I could have misunderstood it though.

As for btrfs, I must admit I have not personally used it at all since
experimenting with it briefly when it was very new, and I was rather
unimpressed that a filesystem could claim to have free space in df but
gave out of space errors if you tried to write files.  To me that was
too unfriendly to work with.  Maybe it has gotten better since.  I sure
hope so.  Of course the fact it ran out of space after 50GB written
to an 80GB drive did not help make me want to play with it further.
That seemed too inefficient.  ext4 has never done me wrong and has always
done everything I expected.