FreeBSD Might Get A Linux Kernel API Wrapper To Help Porting Linux Drivers

[nslay]

Pawlerson,
Don't mention soft updates. It's a nice idea, but soft updates don't work reliably since the disk itself can re-order writes. And needing any sort of fsck (soft updates allows for fsck on a mounted file system) is impractical today with the large disk sizes. FreeBSD 9.x and later have journaling turned on by default. Recovery after unexpected shutdowns is instantaneous now.

[TeamBlackFox]

Journaling isn't exactly consistent either, nor a better option over soft updates. Example:

I had an Arch workstation which had systemd running as PID 1 ( this was March of this year ) I was running some very I/O intensive tasks ( synchronisation of a few server databases had failed so I was using my work station as a synchroniser ) and I had systemd lock up the entire system in a kernel panic. After reboot, the ext4 root filesystem was corrupted badly and so fsck ran. But then after it finished, it ran it again. And again, and again in an endless loop due to a corruption of the super block. Luckily no data was lost, because I dumped the FS using a rescue disk to an NFSv3 server. After recovering the data and analysis of the kernel dump and the journal, there was a serious bug I discovered tied to an interaction between the driver for ext4 and the kernel version I was using and systemd which resulted in I was already distrustful of systemd, but filed a set of bug reports anyways. The systemd one was immediately deleted, and I got a nasty email in which I was called a moron, which shifted the blame to the kernel version I was using ( which was the latest offered by Arch ) and claimed that I caused the problem. Now, conversely the bug I filed regarding super block corruption in ext4 was dealt with professionally. I don't know why the systemd crew is a conceited group of unprofessional dickheads, but I prefer stability to speed any day. And with Runit, Uselessd and OpenRC being just as usable and viable, I don't really see why anyone but RedHat would bother using it.

Since Pawlerson doesn't know why people hate systemd, let me explain why I hate it:

Only compiles for glibc and x86 architectures properly
Uses poorly documented APIs
Obfusticates the boot process
Headed by an unhelpful, conceited and unprofessional group of assholes
Is GNU/Linux specific and therefore isolates 100% of my occupational and personal fleet.
Conversely, I have never had an issue with soft updates, and got pretty pissed when NetBSD deprecated the option. Not saying it is perfect, by any means. I've read the 1999 paper on it and only understood about a 1/8 of the paper, but it is fast and works well for me. I am not, and have never said the UNIX philosophy needs to be abided by rigidly, but if you're going to diverge, do it in a way that makes sense. Perhaps if a new filesystem was developed with soft updates and an I/O scheduler well optimised for it, I am sure it could be improved.

And no, I don't want to reveal my identity and email I used because I know I will face harassment.

[nslay]

TeamBlockFox,
One of the underpinning assumptions in soft updates is that writes reach the disk in order. That way fsck can check for very specific patterns when repairing a file system. But this doesn't happen in reality since the disk itself often reorders the writes. And so, fsck can't work reliably when that assumption is violated. This is why journaling is used now. This is all my limited understanding of soft updates and journaling.