[jordigh]

"WE DO NOT BREAK USERSPACE"

https://lkml.org/lkml/2012/12/23/75

I was surprised to see that Linux has in fact removed other filesystems in the past (and I had to look up the word "senescent").

So the real news to me here is that a somewhat "major" break in userspace is being considered.

Sure, ReiserFS might not be getting a lot of new installs, but the fact that people have submitted fixes to it within the past few years means it has some. There are installs of it out there. Wilcox is considering breaking userspace for some users.

Linux is famous, famous for keeping backwards compatibility for almost everything forever. The stories of Linux backwards compat are up there with stories of Windows still supporting AUX and CON and other special file names. Is "WE DO NOT BREAK USERSPACE" still worthy enough to be shouted at the top of your email lungs?

[chousuke]

Removing a kernel driver does not break userspace.

I mean, yes, your filesystem becomes inaccessible, but any programs that you could run if you could access that filesystem by some other means would still function. None of them depend on ReiserFS specifically for their function.

Userspace breakage is more about changing interfaces in such a way that applications using that interface change their behaviour somehow. This does not apply to removed drivers.

[mrweasel]

You're technically correct, but it would be a "fun" surprise to update your operating system and then not be able to boot because your filesystem isn't supported anymore.

[chungy]

If you're running a rolling release, you should already expect this kind of experience.

If you run a stable distribution, you stay on the older kernel series until you upgrade the entire OS, by which time the release notes would say "Removed support for ReiserFS"

And then there you can do the "tar -c -C /reiserfs . | tar -x -C /ext4" dance (or whatever other preferred copying mechanism), before the OS upgrade.

[samus]

Such big changes rarely happen overnight. If someone really knows about and runs ReiserFS, they can be expected to read up on release notes for major upgrades of their distro. And it's far from an everyday event to even consider deprecating a filesystem. The fact that we are having this conversation rather proves that.

[selfhoster11]

If your application interfaces with ReiserFS directly (fsck/servicing scripts), or you expect to see certain performance patterns (like high speed on lots of smaller files), then I would consider this userspace breakage.

[djur]

In the same sense, Linux broke userspace for 386 users in 3.8 because the users expected Linux to run on their computer. An optional build-time feature being removed does not break userspace.

[selfhoster11]

Arguably yes, abandoning an architecture is breaking userspace. At least for those that are still using it.

[cogman10]

I mean, at the end of the day ReiserFS offers very little special compared to the other options already in the kernel. It never had a huge install base and has always been a major maintenance burden on the kernel.

AFAIK, BTRFS has everything Reiser has with a far better maintenance and ongoing feature expansion.

Really, the only reason to use reiser at this point is because you are dealing with data that you can't, for some reason, move to a new filesystem yet you still want to have updates to the kernel.

[samus]

There is a huge difference between introducing glitches in syscalls and deprecating support for something self-contained like a filesystem. The former is sudden and potentially impacts an unspecified, though presumably huge, number of users. The latter is a filesystem that will be put on a deprecation schedule that will literally take half a decade to go through.

[djur]

Read on: "If a change results in user programs breaking, it's a bug in the kernel." Linux regularly removes features. Entire architectures have been removed, including support for the 386. The alternative would be simply unworkable.

[bityard]

A filesystem in the kernel isn't userspace.

[TheDong]

Isn't "mount -t reiserfs" userspace though? Presumably removing reiserfs from the kernel would also break that use of the 'mount' syscall.

[djur]

The syscall would return ENODEV, just like any other case where a user attempts to mount a filesystem type that isn't compiled for the running kernel.