_kdave

kdave.github.io

> How great Novell and Attachmate were as owners

This is the opposite how I and not only I remember it. Novell did save S.u.S.E. in 2005 by the highly controversial deal. And then started to slowly dissolve its internal identity within the whole company and almost succeeded. The Novell management was incompetent, trying to save it's dying business by bending what SUSE was doing. Barely survived the 2008+ crisis.

Attachmate, another legacy product company was interested in Novell due to assets and customers. That there was a business unit (SUSE) that was quite capable was merely a surprise to the new owners. They let us live and do our jobs. Which paid off because Novell died in a year or so after attempts to salvage it. The Attachmate management wanted to make money, no interest in SUSE. You can call it good management, but mainly due to the fact that the accounting was internally split from Novell and the numbers did not lie.

The secret sauce of SUSE is that it has strong foundation and longtimers that still somehow manage to keep the spirit and attract new poeople who appreciate it in the work environment. The miracle of SUSE it's been able to survive any shitty and clueless top management it had had installed by any of the buyers. So far. Fingers crossed.

I'm glad that research papers don't start with "we've analyzed linux kernel 2.6.18 sources (because this is what we had on our lab machines) and determined that ext3 is the best filesystem for our research purpose and now present you with a novel idea of using high-tech device on that". The paper acknowledges modern features, takes design from other filesystems (mentioned BTRFS and tree structures). Overall the idea is interesting and promising.

By default the metadata profile is 'DUP' (i.e. 2 copies on one device), the same can be done for data but this reduces the usable capacity. On normal HDD or SSD this should not be needed but having both data and metadata DUP/DUP has been useful on raspberry pi with the micro SD card storage. It's not perfect but increases the chances to get the data back if the card is partially damaged due to power spikes.

MDRAID had write hole until 4.4 (2015, https://lwn.net/Articles/665299/) and it had been long awaited back then. ZFS to my knowledge deals with that by variable stripe length that has its own problems but yeah it works. Btrfs changes implementation of the stripe update while preserving the on-disk format (i.e. can't do the same as ZFS without introducing incompatible change), intent log/bitmap have been proposed (which would be the MDRAID approach) but that's another incompatible change. So the 'next one' is at the cost of performance but with same compatibility.

Yeah but monitoring is not something that comes with the filesystem. If you have to set up the system to be a HA and configure monitoring, email notifications whatever, making sure the filesystem is created with redundant profiles, then I'm expecting that also adding the 'degraded' to the fstab is part of the configuration.

AFAIK they use it internally, there are articles on lwn.net how, the use cases is for root filesystems and containers. I'm not sure I understand what you mean by the community sentiment, there are examples of code they'd developed internally first and sent it upstream, but in all cases I remember there were no problems. What can happen in the community is e.g. how the patches are organized or if the changelogs are complete. It's of course easier to develop something internally, if it touches other subsystems or if there's enough coverage just for the new code the test/fix/deploy cycle is much flexible. Once it's supposed to go through mailinlists or convincing other maintainers to accept changes it takes longer and must stick to the development cycle. This benefits both sides in the long run.

The development speed has to balance the schedule of linux kernel development (merge window, release candidates, 3 months cycle) and demand to merge several distinct features or core changes. There are no formal deadlines but we have to make sure that the new code is feasible to be stabilized in the given time. Once a new feature is in the wild some bugs or fixups are still needed so this takes some time from the new development and has to be accounted for.

My strategy to pull new things is to have one big feature that has ideally been reviewed and iterated in the mailinglist or there was a lot of testing already done. In addition two smaller features can be merged, with limited scope, not affecting default setup and possibly easy to debug/fix/revert if needed. Besides that there are cleanups or core updates going on so this should not touch the same code to make testing less painful. With new features the test matrix grows, code might need wide cleanups or generalizaionts before the actual feature code is merged. So this can indeed slow down development.

The raid56 is progressing but until the 6.2 pull from today there was not much to announce regarding stability/reliability. There were proposed fixes but as incompatible features, which means some changes on the user side and with backward compatibility issues. What's pending for 6.2 should fix one of the bad problems at least for raid5.

> It won't boot on a degraded array by default, requiring manual action to mount it

If you want it to behave like that then add 'degraded' to fstab. That a device is missing can have unknown reasons, the user should know better and resolve it or allow such boot. It's not automatic as there's no way to inform the user that it's degraded state.

> it was very unfortunate that Linus chose to dub btrfs as the ext4 successor

That quote is from Ted T'so (https://en.wikipedia.org/wiki/Btrfs#History) or do you have a link to Linus' quote?

Also tools like CUP386 did that for free, but anyway interesting read.

Booting from zoned device on btrfs is not supported, the 0th zone contains the super block and the boot loader data are before any superblock so updating them would require reset and complete rewrite of the live data in the zone.

The 'sparse file file not found' is caused by grub, it would try to overwrite file blocks directly, but on btrfs it would cause checksum mismatch. This has been solved by storing the env block outside of the filesystem at 256K and synced back and forth once the system is booted. 256K is ok as btrfs does not use the first 1M on any device for bootloaders.

Insert a delay before the image is returned by the server, watch who starts complaining.