Announcement

Collapse
No announcement yet.

Another Look At The Bcachefs Performance on Linux 6.7

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • edgmnt
    replied
    Originally posted by cj.wijtmans View Post
    I just dont like sysvinit bash scripts although its more flexible, readable and configurable i just dont have enough experience with bash script to make a proper init script for the life of me.
    It's not just you, non-systemd stuff tended to be duct-taped and essentially broken one way or another, if it could even be done properly. With systemd the executables don't even need to write pidfiles or daemonize themselves anymore. Less privileges, less race conditions and it just works with minimal configuration. If you really want you can set up stuff like socket activation and ensure the stuff comes up properly when and if needed.

    Leave a comment:


  • NotMine999
    replied
    Originally posted by cynic View Post

    good luck with bitrotting data!
    Are you just passing hot air here? Or do you have actual proof to back up your claims?

    I have used Ext4 for all my boot volumes ('/' root & /boot) for the past 15 years simply because it is SOooo easy to recover if something fails.

    Have I had SSDs fail? Yes I have. We just install a new SSD; load up a new copy of the OS (netboot that install so no shuffling of CDs or remembering that specific USB key that rarely gets updated); restore from backup any config files that are different from default; then reboot the system back to where it should be. Application restoral, if it resides on the 'System' drive (but it should not per "house rules"), is handled differently in my shop.

    Sure, disk imaging using something like Clonezilla would be a useful idea for our 'System' drives, but my administrative/development/teaching time is limited. The few "house techs" on staff know how (and have documented procedures) to replace hardware, netboot an OS install, and restore config files from backup ... among other tasks.

    YMMV
    Last edited by NotMine999; 30 November 2023, 10:05 PM. Reason: Just because I can

    Leave a comment:


  • S.Pam
    replied
    Was sqlite configured in WAL mode, or are the sqlite tests still using legacy setting (delete)? WAL is used by anything needing performance on any fs, and especially COW filesystems.

    Leave a comment:


  • carewolf
    replied
    Originally posted by Berniyh View Post
    Well, it failed me 3 times in the last 10-15 years. btrfs, so far, has not yet failed me in roughly the last 10 years. So now what?

    Of course, nothing can actually repace backups other than more backups.
    But, as an ext4 user, how do you even know that you have faulty data and that you need your backup?
    tbh, (data) checksumming support should be a standard thing in filesystems today.

    (Edit: and yes, that's what happened to me. Faulty data I noticed by pure coincidence.)
    I have had btrfs eat all my data twice, which is two time more than any other FS in over 35 years of using computers. The fucking problem with it is that it doesnt have an fsck that can actually repair errors, and as a safety measure it just refuses to do ANYTHING if there is one bit of error anywhere.. I only use it for git back sources now, that I can always recover, but no way I ever put anything else on bitrotfs. So you don't just quitely rot one bit of data, but instead you lose EVERYTHING because it was badly designed.

    Though to be fair, both loses was like 10 years ago. Not had any problems with btrfs in 10 year
    Last edited by carewolf; 30 November 2023, 04:47 PM.

    Leave a comment:


  • clipcarl
    replied
    Originally posted by hyperchaotic View Post
    And by a monolithic beast you mean a highly modular init and runtime management/admin system comprising many optional components each with their own purpose.
    Systemd fans like to claim that it's really super-modular but the reality is that most distributions that include it do so in a monolithic package and / or with package inter-dependencies that generally enforce installing and running its sub-components. For example, try installing a desktop environment on a Systemd-based distribution without say systemd-logind. The reality on this planet is really closer to Systemd being one big take-it-or-leave it monolith than to the "highly modular" system you claim if users want to compile their own packages and create their own distribution.

    I'm a bit older than probably most of you here so I actually know and remember from my own professional experience what made Unix (and now Linux) such a force to be reckoned with over the last 40+ years. It really was in large part due to the KISS (Keep It Simple, Sir) philosophy. For Unix and Linux that boiled down to the idea that each program does exactly one thing and does it well. In practice this allowed vendors of integrated solutions to customize their systems to their specific needs in a way that's not as easy with more monolithic, tightly integrated software stacks. Need a `login` with different features? Just replace it with a different one without having to worry too much about it breaking half the system. Same thing for `syslogd`, the initrd system and lots of other things that have been and are being consumed by Systemd.

    Personally I haven't figured out what problem(s) Systemd is supposed to solve that no other system can in the more traditional way. Which is part of the reason why I run Alpine Linux (with OpenRC) on my personal servers and Artix Linux (with OpenRC) on my personal workstations. Obviously professionally I do have to deal with Systemd, though.

    It's a matter of personal preference and people can run whatever they want. But it does annoy me a little that pro-Systemd people often appear to go out of their way to make it much more difficult for useful software to be used without Systemd seemingly for no real benefit to the users. Obviously, that could simply be a matter of erroneous perception but it does sometimes seem that way.

    Leave a comment:


  • Berniyh
    replied
    Originally posted by cj.wijtmans View Post

    X11 is not the reason linux became popular though. Especially when many users had issues with it especially nvidia users.
    So what "KISS" part made Linux become popular in your opinion?

    Leave a comment:


  • cj.wijtmans
    replied
    Originally posted by Berniyh View Post
    Really? I can think of many things that made Linux popular, but this isn't one of them.
    I wouldn't even agree that it's really part of the core development technique for most tools.
    I mean … one of the core components in the Linux ecosystem was/is X11 and that fails hugely in terms of KISS.
    X11 is not the reason linux became popular though. Especially when many users had issues with it especially nvidia users.
    Last edited by cj.wijtmans; 30 November 2023, 03:35 PM.

    Leave a comment:


  • cj.wijtmans
    replied
    Originally posted by hyperchaotic View Post

    And by a monolithic beast you mean a highly modular init and runtime management/admin system comprising many optional components each with their own purpose.
    Do you apply this logic to xorg too?

    Leave a comment:


  • clipcarl
    replied
    Originally posted by waxhead View Post
    Personally i think filesystem tests should be performed on a block device in ram.
    Strongly disagree. That would capture theoretical performance that has nothing at all to do with how the filesystem would perform in the real world. IMHO the most useful benchmarks are those that capture real-world workloads run on a system that's reached steady-state.

    Leave a comment:


  • clipcarl
    replied
    A few questions / points:
    • Why was a 512 byte block size used for bcachefs but 4k for all the other filesystems? SSDs virtually always perform much better with a 4k block size (though I haven't personally tested the difference on bcachefs).
    • This article doesn't mention whether the bcachefs `discard` option was enabled. For this to be a fair test, that option should probably be disabled. (Bcachefs basically does a "trim" on its own as blocks are freed when that option, which is on by default, is enabled. Trim operations are usually pretty slow especially on consumer SSDs. The other filesystems don't automatically trim blocks-- the administrator needs to manually run something like `fstrim` and thus the trim penalty wouldn't be included in their results.)
    • ​This article doesn't mention what was done in between filesystems to reset the SSD back to its "factory" state. Without this, the filesystems tested first would have a huge advantage over the filesystems tested later. You can't even just wait an hour or a day or whatever between tests. Something like using `nvme format /dev/nvme0n0 -s 2` might work (but double check for the specific drive). For SATA drives, usually a security erase does the trick and that `nvme format` command does something similar for NVME drives. Or simply use a different identical brand new SSD for each filesystem's tests. If you're not sure how to do a complete reset of the drive's state something like `blkdiscard /dev/nvme0n0` would be much better than nothing. (But in any case see the caveat below.)
    • Because SSDs do garbage collection in the background, in order to get the most accurate results the tests should be run in the same order for all the filesystems with no other filesystem operations besides the tests. The amount of time before and in between each test should also be the same. I'd recommend using a script that includes the reset and every test so there's zero time in between tests. Was that done here? Manually starting individual tests when you get around to it is a good way to get non-meaningful results (I have no reason to believe that was done here).
    • The Flexible IO Tester (fio) results (up to 1.5m IOPS) appear to suggest that the test setup was one that I wouldn't consider useful because it is only testing how quickly the SSD's controller can talk to its DRAM cache for very short bursts and not what the SSD can actually sustain over time. No SSD can really do 1.5m random 4k IOPS actually writing to the flash. (SSD manufacturers advertise that same largely useless kind of number for their consumer SSDs I guess because they assume that regular consumers and reviewers don't know better. Enterprise SSD spec sheets usually show much more useful sustained IOPS which is why enterprise SSD numbers can often at first glance look a lot slower even though they're often much faster in reality.) IMHO, if you're going to go through the trouble of running fio tests they should be set up with a large enough random dataset to completely overwhelm the SSD's DRAM and SLC caches and actually measure what the SSD can sustain over long periods of time.
    • To make sure the benchmark numbers for each filesystem are as accurate as possible, the entire test run for all filesystems should be repeated multiple times. For example, 3 times on 3 successive days. If your results for a particular filesystem aren't reasonably close on each day you ran them then you know your test environment and controls need more work.
    Caveat: For SSDs, benchmarks from a brand-new-out-of-box state (or a factory reset state) represent a best-case very short period of time scenario. The same is true for newly formatted filesystems in general regardless of the medium. I.e., you likely won't get the same performance once you're system has been running for a day / month / year and as the filesystem fills up with data. For people like me who have built storage systems for work, benchmark runs designed to capture steady-state or worst-case performance are far more useful.

    Leave a comment:

Working...
X