OpenBSD Journal

Soft updates (softdep) support removed from -current

Contributed by rueda on from the don't-hold-your-breath dept.

Support for soft updates (softdep), disabled since before the 7.4 release [see earlier report], has been removed from -current by Bob Beck (beck@):

CVSROOT:	/cvs
Module name:	src
Changes by:	beck@cvs.openbsd.org	2024/02/03 11:51:59

Modified files:
	bin/ps         : ps.1 
	sbin/dump      : traverse.c 
	sbin/dumpfs    : dumpfs.c 
	sbin/fsck_ffs  : dir.c fsck.h main.c pass1.c pass2.c pass5.c 
	                 setup.c 
	sbin/growfs    : growfs.c 
	sbin/quotacheck: quotacheck.c 
	share/man/man5 : fs.5 
	sys/conf       : files 
	sys/ddb        : db_interface.h 
	sys/dev        : softraid.c 
	sys/kern       : kern_physio.c spec_vnops.c vfs_bio.c vfs_subr.c 
	                 vfs_sync.c vfs_syscalls.c 
	sys/sys        : buf.h mount.h proc.h vnode.h 
	sys/ufs/ffs    : ffs_alloc.c ffs_balloc.c ffs_extern.h 
	                 ffs_inode.c ffs_softdep.c ffs_softdep_stub.c 
	                 ffs_vfsops.c ffs_vnops.c fs.h softdep.h 
	sys/ufs/ufs    : inode.h ufs_extern.h ufs_inode.c ufs_lookup.c 
	                 ufs_vnops.c 
	sys/uvm        : uvm_swap.c 

Log message:
Remove Softdep.

Softdep has been a no-op for some time now, this removes it to get
it out of the way.

Flensing mostly done in Talinn, with some help from krw@

ok deraadt@

(Comments are closed)

Comments

  1. By Anonymous Coward (2a02:1810:953e:4600:8d68:ca8:2801:3a14) on

    Softdep had its days, and I'm excited for what's to come, now that the softdep hurdle has been cleared.

    Comments

    1. By Sebastian Rother (2001:9e8:fb1:1900:75f4:dcd8:72d6:2bc2) gerd.sebastian.rother@googlemail.com on

      NOTHING will come! Even the IN-KERNEL NTFS allows you to crash OpenBSD just by READING FILES. Not enought Manpower to include something new FANCY! What I do not understand: Why is NTFS not dropped too? OpenBSD can load NTFS via FUSE then IMPROVE FUSE if you like. But the IN-Kernel NTFS leads to "Issues". I reported a Bug YEARS ago: Nobody cares and the Bug is reproduceable very easily.

      Comments

      1. By Ed GIrard (57.140.28.45) on

        Wherever you reported this, it wasn't to openbsd-bugs.

        Comments

        1. By Sebastian Rother (2001:9e8:f87:1500:398d:21af:b1f1:a2c1) gerd.sebastian.rother@googlemail.com on

          REALY?

          STRANGE:
          1:
          https://marc.info/?l=openbsd-bugs&m=164815065807138&w=2
          2:
          https://marc.info/?l=openbsd-bugs&m=164798229510058&w=2

          It even has NTFS in the SUBJECT.

          Comments

          1. By Ed Girard (57.140.28.45) on

            Sorry, didn't find you as the author of that. Apologies.

            Comments

            1. By Sebastian Rother (2001:9e8:f87:1500:398d:21af:b1f1:a2c1) gerd.sebastian.rother@googlemail.com on

              Accapted BUT: You did not searched for NTFS (wich was a FAULT since I clearly pointed out the Topic).

              Please do accapt another BUG REPORT below. The Installer is F'ed and allows any sane User to render the Installation kind of USELESS.

              Comments

              1. By Ed Girard (57.140.108.45) on

                I'm not a developer, so I don't accept bug reports.

                I remember when NTFS write was removed a decade or so ago, and I concluded that my best path forward was to use mostly Windows to deal with NTFS, rather than make enraged posts to misc demanding that the devs do things for me. Have you submitted patches that were rejected?

                I realize that you might be constrained by working in an OpenBSD-only shop where Windows is forbidden. Although that seems unlikely.

        2. By Anonymous Coward (2001:9e8:f87:1500:398d:21af:b1f1:a2c1) on

          Since you where so FRIENDLY, allow me to put you another Bug STRAIGHT into your FACE:

          if you do install OpenBSD, the Installer allows you to change your Keyboard Layout. You can choose to ENCRYPT the Installation:

          If you do REBOOT, your INSTALLATION is RENDERED USELESS since the Decrypter ASSUMES US-Layout so you can not enter your Password (wich you used during the installation).

          BRILLIANT!

          Next one: Same SETUP but you choose to use a SERIAL CONSOLE! So you ENCRYPT the Installation, you know NOBODY TESTED THIS SHIT since the Decrypter is not able to use an äößü or any other normal special Charackter (for wich you will need a US Layout or a Photo of one to know where ^ & or ; are) so you use a WEAK Password like "test" wich you can ENTER since the Developers did not tested their Implementation.

          Now what Happens? GUESS: You can not REBOOT a Device where your Console is directed to COM0 because the DECRYPTER is run BEFORE the REDIRECTION of your CONSOLE so it REQUIRES a PHYSICAL KEYBOARD being attached.

          WHY would I redirect my Console to COM0 if I need a PHYSICAL KEYBOARD attached to DECRYPT the Installation?

          So: This "BUG REPORT" is for FREE! As you can see: Even the MOST SIMPLE LOGICS are not working so what do you Exspect from the Developers? Fixing Filesystems? They might can programm a Networkstack but they clearly can't test even their own Installer or their HDD-Encryption.

          Comments

          1. By Anonymous Coward (14.162.6.124) on

            > Next one: Same SETUP but you choose to use a SERIAL CONSOLE! So you
            > ENCRYPT the Installation, you know NOBODY TESTED THIS SHIT since the
            > Decrypter is not able to use an äößü or any other normal special
            > Charackter (for wich you will need a US Layout or a Photo of one to
            > know where ^ & or ; are) so you use a WEAK Password like "test" wich
            > you can ENTER since the Developers did not tested their Implementation.

            > Now what Happens? GUESS: You can not REBOOT a Device where your Console
            > is directed to COM0 because the DECRYPTER is run BEFORE the REDIRECTION
            > of your CONSOLE so it REQUIRES a PHYSICAL KEYBOARD being attached.

            > WHY would I redirect my Console to COM0 if I need a PHYSICAL KEYBOARD
            > attached to DECRYPT the Installation?
            This is incorrect. Tested with OpenBSD VMM.
            Well, OpenBSD switch the console to com0 AFTER you enter passphrase,
            but I can still enter my passphrase. Guess why?

            Comments

            1. By Anonymous Coward (45.138.16.42) on

              > Well, OpenBSD switch the console to com0 AFTER you enter passphrase

              In other words, what [s]he said wasn't incorrect, and in fact was totally accurate.

          2. By Anonymous Coward (2a09:bac3:a649:197d::28a:b3) on

            When a community makes an apple orchard, and invites people to enjoy the fruits of their labor for free, enjoy the apples, worms and all.

            Comments

            1. By Sebastian Rother (2001:9e8:f95:3900:9908:915f:6760:6995) gerd.sebastian.rother@googlemail.com on

              You don't get the Point!

              Something is FUNDAMENTALY BROCKEN in the NTFS-Code... it is useless!
              If I give you a Cake for FREE but it's poisoned... would you ENJOY it?

              And do not get me WRONG but: IF NOBODY, realy NOBODY, cares about NTFS: Would it not be better to remove the Support then to put your DATA in danger? THAT is why SOFTDEP was removed, right?

              Like somebody wrote here: TRIM SUPPORT was submitted a DECADE ago, never implemented because it conflicted with SOFTDEP (wich is now GONE).

              So removing NTFS (from the Kernel) and focussing on FUSE is the way to go for OpenBSD since OpenBSD has not enought Manpower and lacks fundamental Expertise in the FIlesystem Area.

              Kind regards,
              Sebastian Rother

            2. By Anonymous Coward (45.80.158.205) on

              > When a community makes an apple orchard, and invites people to enjoy the fruits of their labor for free, enjoy the apples, worms and all.

              I find this kind of response to genuine, constructive criticism, rather disingenuous and annoying. I agree that many people whine too much, but nothing is perfect, and what's wrong with pointing out significant issues?

      2. By Anonymous Coward (49.12.42.182) on

        Hey cool, I like these anonymous coward postings they don't require one to log in. Could be good.

        I think the main reason is that people don't care based on who you are, not that you have anything good or bad to say. Isn't it like that everywhere nowadays?

        Best,
        -peter philipp

      3. By Anonymous Coward (2a00:23ee:16c0:2026:46f:379b:bf2b:fcb8) on

        There has been lots of work done to improve FUSE, but commits were vetoed.

    2. By Anonymous Coward (46.23.93.11) on

      As others’ve already said — probably nothing, OpenBSD has notoriously bad filesystem and storage subsystems.

      Comments

      1. By Anonymous Coward (45.138.16.42) on

        Perhaps this could improve now that softdep isn't all over the place in the VFS layer. There's probably a reason why it didn't catch on, lack of ability to layer cleanly.

        Meanwhile, have you seen the state of Linux file systems? There are so many to choose from embedded in the kernel (and why, when FUSE is available), and a few are buggy (eg btrfs) to say the least.

        Comments

        1. By Anonymous Coward (5.18.238.154) on

          > Meanwhile, have you seen the state of Linux file systems? There are so many to choose from embedded in the kernel (and why, when FUSE is available), and a few are buggy (eg btrfs) to say the least.

          This is pure copium. Linux filesystems are reliable enough to power most of the Internet.

          Comments

          1. By Anonymous Coward (45.80.158.27) on

            Not copium. Most of the internet is like modern society: fragile and fucked up. Most of the internet is running using software and hardware of dubious quality, but because small bits are getting replaced at a time and not the entirety of the internet, people barely notice when things go down. Security breaches happen, but they're in the news for a day or two before being brushed aside.

            The point being, the grass isn't always greener on the other side. Linux FS layers perform very well compared to OpenBSD without a doubt, but how clean is the code base really? Now they're talking about having multiple incompatible languages as a requirement for the kernel (Rust and C/C++). Perhaps Andy Tanenbaum was onto something all these years ago when he was championing microkernels, and some like L4 perform IPC very well. May be worth a re-visit since modern hardware is so different to that of yesteryear when a microkernel may have incurred a noticeable performance penalty.

            Comments

            1. By Anonymous Coward (5.18.238.154) on

              > Not copium.

              You know many OpenBSD storage servers out there? Me neither.

              > Most of the internet is like modern society: fragile and fucked up.

              Maybe. But it also works reliably enough to be usable.

              > The point being, the grass isn't always greener on the other side. Linux FS layers perform very well compared to OpenBSD without a doubt, but how clean is the code base really?

              Pretty clean. You have som examples of the opposite?

              > Now they're talking about having multiple incompatible languages as a requirement for the kernel (Rust and C/C++). Perhaps Andy Tanenbaum was onto something all these years ago when he was championing microkernels, and some like L4 perform IPC very well. May be worth a re-visit since modern hardware is so different to that of yesteryear when a microkernel may have incurred a noticeable performance penalty.

              Nothing wrong with Rust there. Its a promising language.

              Comments

              1. By Anonymous Coward (45.80.158.205) on

                > You know many OpenBSD storage servers out there? Me neither.

                No but I know plenty of ones that use Windows. You missed the point, it's not that storage is better on OpenBSD, but that the subsystems on Linux are also quite shocking.

                > Maybe. But it also works reliably enough to be usable.

                But it's still fragile and fucked up. It's like hacking together a system and using gaffer tape to mount the components. It works "reliably enough to be usable" but it's still bodged together.
                Perhaps also worth noting, much of the Internet runs other operating systems too, including Windows, so one can argue that if the internet really is as stable as you champion, Windows is playing a part in it. I recall some ISPs use OpenBSD in their BGP nodes also.

                > Pretty clean. You have som examples of the opposite?

                Let's see, hacks for certain SSDs because trim doesn't behave on Linux without them, BTRFS crashing the entire kernel when it pleases, dramas surrounding "bcachefs", etc.
                Not that OpenBSD's one is much better, but overall neither is Linux's one. It may be a better performer but it has its own set of problems.

                > Nothing wrong with Rust there. Its a promising language.

                Again you miss the point completely. Rust and C being intermixed with one another in a single kernel, requiring bindings and other such overheads. Instead of one of the languages being used. If modules such as drivers etc were separated, it wouldn't matter if Rust was used for some modules with the core kernel being C/C++, or even vice versa.

                As for the Rust language itself, it may be promising but the specification isn't even stable yet and keeps changing. And don't get me started on the gatekeepers of the "Rust community" who have publicly expressed pride in barring those engaged in "wrongthink/wrongspeak".

                Comments

                1. By Anonymous Coward (5.18.238.154) on

                  > No but I know plenty of ones that use Windows. You missed the point, it's not that storage is better on OpenBSD, but that the subsystems on Linux are also quite shocking.

                  Shocking how? do they have bugs? yes. do they look unmanageable and noone can read them? certainly not.

                  > But it's still fragile and fucked up.

                  Again, how so? I crash my vms on purpose to get coredumps in order to analyze kernel bugs like deadlocks all the time. And things just work, no FS damage that journal replay cant fix.

                  > It's like hacking together a system and using gaffer tape to mount the components. It works "reliably enough to be usable" but it's still bodged together.

                  Metaphors =! proofs.

                  > Perhaps also worth noting, much of the Internet runs other operating systems too, including Windows, so one can argue that if the internet really is as stable as you champion, Windows is playing a part in it.

                  Windows is pretty damn stable. Hell, it holds its market share for years despite having free Linux and BSDs.

                  > Let's see, hacks for certain SSDs because trim doesn't behave on Linux without them, BTRFS crashing the entire kernel when it pleases, dramas surrounding "bcachefs", etc.

                  So? quirks for hardware are quite normal, every os has them. Bugs? Of course we have them, OpenBSD crashes all the time.

                  > Not that OpenBSD's one is much better, but overall neither is Linux's one. It may be a better performer but it has its own set of problems.

                  Both have bugs. But Linux stack is still much more reliable. Om not worrying about my Linux vm crashing, yet Im almost sure that my OpenBSD vm will end up being corrupted.

                  > Again you miss the point completely. Rust and C being intermixed with one another in a single kernel, requiring bindings and other such overheads.

                  overheads? 1-2% for not having stupid C bugs? bring it on.

                  Comments

                  1. By Anonymous Coward (2a0b:f4c2:1::1) on

                    > Shocking how? do they have bugs? yes. do they look unmanageable and noone can read them? certainly not.

                    Yes, anyone can read them if they try hard enough, and people do maintain them. Does that mean they're ideal?

                    > Again, how so? I crash my vms on purpose to get coredumps in order to analyze kernel bugs like deadlocks all the time. And things just work, no FS damage that journal replay cant fix.

                    VMs on Linux in general are quite stable (presume you're using KVM also?) so no surprises there. I have had FS damage on Linux more often than I have had it on other operating systems (including OpenBSD), and have seen particularly nasty crashes and hangs on SSDs. I had to change file systems from btrfs to ext for example to reduce the crashes.

                    > Metaphors =! proofs.

                    Proofs for what? You wanted examples, I gave you examples.

                    > Windows is pretty damn stable. Hell, it holds its market share for years despite having free Linux and BSDs.

                    And, dare I say it, orders of magnitude more stable than Linux in my experience. It's a shame it has so much bloatware/adware/spyware/licencing and corporate crap on it that is insanely hard to remove, though the server ones aren't bad.

                    > So? quirks for hardware are quite normal, every os has them. Bugs? Of course we have them, OpenBSD crashes all the time.

                    Now THIS is copium! I could say the same about your response, "OpenBSD crashes all the time." which has not been my experience. In fact I've often had OpenBSD much more stable than Linux, and working on hardware that Linux needs lots of hoops and messy config to get working correctly. YMMV?

                    > Both have bugs. But Linux stack is still much more reliable. Om not worrying about my Linux vm crashing, yet Im almost sure that my OpenBSD vm will end up being corrupted.

                    Apples vs oranges here. I agree Linux's VM layer is far superior in terms of performance and reliability, I didn't say it wasn't. In my experience though, the rest of the Linux stack is terrible, the only reason I tend to use it is because of far superior software support. I often use WINE and other complex applications which would have no hope of being ported to OpenBSD.

                    > overheads? 1-2% for not having stupid C bugs? bring it on.

                    Sure, now we end up with stupid Rust bugs intermixed with the stupid C bugs. Same shit, different boss.

    3. By Anonymous Coward (14.162.6.124) on

      Have you actually used ext4, FreeBSD UFS2, ZFS, etc..?

  2. By John McCue (jmcunx) jmcq66@comcast.net on

    As I figured when this was first announced for 7.4, with my workflow I have not noticed a difference :)

    Comments

    1. By Anonymous Coward (45.138.16.42) on

      that is, until the power suddenly goes out or your system crashes in the middle of a disk write.

  3. By Anonymous Coward (45.138.16.42) on

    I think now that softdep is gone, some of the old patches that didn't quite make it can be revisited?

    For example, Ted Unangst wrote patches for TRIM support back in 2011:
    https://flak.tedunangst.com/post/lessons-learned-about-TRIM
    https://marc.info/?l=openbsd-tech&m=131006003118304&w=2

    The first reply to that thread says it all:

    > If you do try the "full trim" diff from Ted, you should not use
    > softdep. The softdep is making some assumptions and taking some
    > rather nasty actions when ffs_blkfree returns early.
    >
    > Test softdep, but not with trim.
    > Test trim, but not with softdep :)

    Comments

    1. By d.c. (81.0.232.249) on

      Well, TRIM, maybe better caching, maybe some cleanup, would be very great goodies. But on the other hand, I guess we need a smart replacement for softdep. It never let me down. I can't say that about Linux FSs.

      And yes, there are scenarios, where I need to run Linux just because being slower about 5 times simply can't fit into the time frame (mostly backups)...

      Comments

      1. By Anonymous Coward (2605:6400:30:fa92:5f11:1ed9:9615:fcc6) on

        It's called "journaling" and has been in use for decades.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]