Reiser4 File-System Port To The Linux 4.20 Kernel

[xorbe]

Who is using and maintaining Reiser4, and why would anyone use it over ext4 / xfs? The only technical reason I could find is that you have lots of really tiny files that could be packed into a single 4K block. Otherwise, anything else is probably a better choice.

[V10lator]

To what are you referring?

IIRC they pretty much abandoned development of Reiser3 to work on Reiser4 stating Reiser3 would be good enough until Reiser4 is ready for primetime (where at that time it was far away from). Nobody wants that situation to happen again just because Reiser devs want to start the next big thing. IIRC this is also why distros switched away from it (Reiser devs pretty much told them to wait for Reiser4 if they reported bugs but at the same time it was known a switch from Reiser3 to 4 will require a full reformat. Reformating to another maintained FS fixed the bugs without waiting for Reiser4, so...).

[Grogan]

I used Reiser4 once, and found that I couldn't even compile glibc because it barfed on timestamps, due to bugs. I would imagine that's been fixed years ago, but that's an example of why you don't put shit like that in the kernel (It wasn't, I did it) and hope it's going to be fixed and maintained.

[nils_]

I don't think I said corporations can be maintainers, only that company backing is usually required.

Can you point to an example? I have never heard of code being rejected for lack of corporate sponsorship, and there are quite a few drivers relying on reverse engineering because some vendors can't be bothered to support their own hardware, sometimes trying their best to make the life of users and developers difficult.

[starshipeleven]

Can you point to an example? I have never heard of code being rejected for lack of corporate sponsorship, and there are quite a few drivers relying on reverse engineering because some vendors can't be bothered to support their own hardware, sometimes trying their best to make the life of users and developers difficult.

I never said code is rejected because of lack of corporate sponsorship directly. I said that corporate sponsorship is usually required to get something merged. I guess I need to be more blunt for the sake of language barrier issues.

To rephrase: I'm not saying that a company sponsor pays some secret Illuminati guardian to have the permission to contribute in Linux, I'm saying that the higher code quality standards in the kernel usually require someone working on that as a job for anything that isn't some bug fix or feature addition or relatively small addition to existing code.
A full general-purpose modern filesystem does usually qualify for the "needs some corporate backing" as it is complex enough to need some serious amount of development to not suck.

Complex contributions submitted by volunteers can (and were) effectively "rejected" by asking to make significant changes that volunteers won't do in their spare time, just because they can't. Maybe it's not their fault as they started from a crappy GPL code drop, maybe they do have limited time so they can't refine their submission to the high standards required by the kernel.

Complex contributions like a whole new driver or anything resembling a modern filesystem usually require someone working on them as a job, which usually implies some bigger entity employing him. It's not a stated "hard" requirement, but it is very common "de-facto" requirement.

An example of this was the ordeal to get BFQ scheduler accepted in the kernel, where they kept shifting the goalposts for years up to the point of requiring him to make it work with the new multiqueque scheduler (which was not even fully stable nor even enabled by default now and afaik still has some bugs now like that ext4 corruption issues) before finally letting it in.

Meanwhile, we got a new scheduler like Kyber that basically got in without firing a shot, that was already targeting the multiqueque scheduler and all. And guess who is the contributor? Facebook devs.

Another example could be some random Realtek USB wifi ac drivers you can find on github, where the original code comes from a GPL code drop of the usual questionable quality from Realtek themselves, and none even bothers to upstream it as they fully know it's a PITA to get it to reasonable quality.

Or there was a friggin kernel subsystem maintainer developing some thermal sensors driver, see the article https://phoronix.com/scan.php?page=n...x-Driver-Axing that had is own out-of-tree hackish fork of the very same driver he is a maintainer of, that would have required massive PITA to upstream and instead of even trying to upstream it decided to just delete the repository to stop people from spamming him with support requests about shit hardware that would have required a ton of reverse-engineering to get anywhere.
(this is a fork of his repo before he deleted it https://github.com/bobafetthotmail/it87 sadly all the github issue threads where he went into more details about the issues are all gone when he cancelled the repo)

[cjcox]

Just setting the record straight... (since I may have started too much of a good discussion)... the problem is ongoing support. What was happening and not all that many years ago, is that driver work was done but not maintained causing compilation issues and even possibly instability and security issues. Thus, if there is no dedicated support ongoing for reiser4, then you don't really want it in the kernel. And I don't believe that Mr. Shishkin has offered to be the maintainer, just a developer.

Anyway, I was surely attempting to foster good discussion on the matter.

Reiserfs (thanks J.Hobbs for all the maintenance) was dissed by Red Hat, which shouldn't be viewed the same as what is being discussed, but sadly, it is often considered the same. Ext2 (and following), while primitive, isn't without its flaws... some of which I believe are still there btw. Just no one killing people while doing development. Xfs has improved and certainly was adopted by Red Hat as an "answer" to having a more enterprise level filesystem and while it is still not excellent, it has grown by leaps and bounds. Personally, I had (have?) high hopes for btrfs, Mr. Mason's creation, and it's a good example of something being adopted that actually has more similarities to reiser4.... which just makes one wonder (revenge against Hans Reiser, maybe the "true" reason?).

Let's just say the door is still open for the filesystem of the future. There's f2fs, nilfs2, btrfs and those weird attempts at gluing volume management, RAID to try to be ZFS-ish (I guess that's a tribute to ZFS, but hardly necessary... ZFS is not without some major warts).

Ultimately reiser4 will likely never be in the kernel... regardless of sponsorship... I say that because very similar things are in the kernel today.

Hans' legacy I suppose.

[starshipeleven]

I had (have?) high hopes for btrfs, Mr. Mason's creation, and it's a good example of something being adopted that actually has more similarities to reiser4.... which just makes one wonder (revenge against Hans Reiser, maybe the "true" reason?).

Lol wtf is this "revenge" bs. The reason was mostly that btrfs developers actually changed the code to conform to kernel coding standards and use kernel facilities as requested by kernel maintainers instead of posting hilarious and ultimately useless flame on the mailing list while refusing to change a thing. This is all documented and available in the mailing list archives.

Let's just say the door is still open for the filesystem of the future. There's f2fs, nilfs2, btrfs and those weird attempts at gluing volume management, RAID to try to be ZFS-ish (I guess that's a tribute to ZFS, but hardly necessary... ZFS is not without some major warts).

It's not "hardly necessary", it's the only sane way you can implement them for those filesystems. Btrfs, bcachefs and zfs can't use normal RAID and volume manager due to their flagship features (checksumming for example).

[cjcox]

(went bezerk)

Take a chill pill.

My point is that btrfs was very much a Mason thing and his employment has wandered around (many companies that is/are very anti-FOSS)... you could argue that it might be a volatile project.

While it is very true that working with Hans (do we work with him NOW... no) was problematic, the team eventually started giving in to the idea of sharing their stuff in a way that could be leveraged by other filesystems. So, while documented, it's fully documented, so you can read all of it and not just the bad stuff. Doesn't mean Hans was a great man... he's a murderer after all. My revenge comment was with regards to reieser4, and I stand by that.

With regards to the "gluing" example, I was referring to things like Stratis. ZFS (and all-in-one) was created by a company that had a hideous volume management solution and an ultra primitive poorly performing filesystem and where using hardware RAID was always considered anathema (basically they had non-existent enterprise storage). It was amazing at Sun because what they had was utter crap.

One could argue that moving from a layered approach to an "all in one" is very Reiser-ish (or maybe ZFS-ish, just to not offend). But Stratis is really just a layered veneer AFAIK, so back to the whole "hardly necessary" thing (but willing to let Stratis surprise me... as IBM, our new kernel overlords, poopoo's on Btrfs).

[starshipeleven]

Take a chill pill.

Don't take dissent with your ideas as being angry at you. I'm not even mad.

My revenge comment was with regards to reieser4, and I stand by that.

My answer to your comment was about Reiser4 mainlining. It's all well documented how he refused to comply to kernel maintainer requests about code and went full flamewar.

Then not enough was done until the company went bankrupt, and without a company backing up the development they don't have the resources to deal with upstream requirements, so it remained out of tree in "life-support" mode.

Any attempt at making this look like some kind of political or personal issue is bs, and exactly how Reiser himself tried to spin it in his hilarious flamewar I mentioned.

ZFS (and all-in-one) was created by a company that had a hideous volume management solution and an ultra primitive poorly performing filesystem and where using hardware RAID was always considered anathema (basically they had non-existent enterprise storage). It was amazing at Sun because what they had was utter crap.

This still does not change one bit what I said. So-called "next-gen" filesystems have to include volumes and RAID in their own filesystem layer due to technical reasons (i.e. they can't use effectively other kernel features as other more simple filesystems can).

One could argue that moving from a layered approach to an "all in one" is very Reiser-ish (or maybe ZFS-ish, just to not offend).

That's pretty easily explained.

Reiser4 has (or was supposed to have, I'm not up-to-date on the current status) a ton of "next-gen filesystem" features, it was supposed to be a "next-gen filesystem", in the same category of ZFS and Btrfs (and bcachefs).

So yeah, I'd say it is not really surprising that it adopted the same "all in one" approach of other filesystems in its same category.

But Stratis is really just a layered veneer AFAIK, so back to the whole "hardly necessary" thing

Stratis is a wrapper to use XFS, LVM and mdadm raid, which is all stuff you can already use right now.

I personally don't mind having a unified interface to control all this stuff, I mean it's offering honestly useful and stable features anyway even if it's not as cool as next-gen filesystems.

[nils_]

Stratis is a wrapper to use XFS, LVM and mdadm raid, which is all stuff you can already use right now.

I personally don't mind having a unified interface to control all this stuff, I mean it's offering honestly useful and stable features anyway even if it's not as cool as next-gen filesystems.

Yeah, there is also some new stuff in there like block level compression and deduplication (VDO): https://github.com/dm-vdo/kvdo
However I wonder how bad the performance impact is compared to using a "next-gen" filesystem. dm-integrity for example requires a journal.