I don't see how a virtualised NVMe disk is different from a physical one.

Especially if you don't have control over the underlying hardware (so you don't know if it has power-loss-protection PLP SSDs), you should send the FUA.

> O_DATA_SYNC

You mean `O_DSYNC`?

Why would you need `O_DSYNC` on-premise, but not on cloud VMs? (Or are you saying you'd include it everywhere?) Similar to my above point, surely it is the task of the VM to pass through any FUA commands the VM guest issues to the actual storage?

Further: Is `O_DSYNC` actually substantially different from writing and then `fdatasync()`ing yourself?

My understand is that no, it's the same. In particular, the same amount of data gets written. So if you believe that to avoid the "can trigger an order of magnitude more I/O" by avoiding `fdatasync()`, you would re-introduce it with `O_DSYNC`.

However, I suspect that that whole consideration is pointless:

The only thing that makes your O_DIRECT+preallocated-only-overwrites writes safe are enterprise SSDs with Power Loss Protection (PLP), usually capacitors.

On those SSDs, NVMe Flush/FUA are no-ops [1]. So you might as well `fdatasync()`/`O_DSYNC`, always. This is simpler, and also better because you do not need to assume/hope that your underlying SSDs have PLP: Doing the safe thing is fast on PLP [2], and safe on non-PLP.

    [1] https://news.ycombinator.com/item?id=46532675
    [2] https://tanelpoder.com/posts/using-pg-test-fsync-for-testing-low-latency-writes/

Let me know if I got anything wrong.

The only remaining question is: Why do you then see any difference in your benchmark?

    Configuration            Throughput (obj/s)
    -------------------------------------------
    ext4 + O_DIRECT + fsync             116,041
    Our engine                          190,985

The first suspicion I have is: Shouldn't you be measuring `+ fdatasync` instead?

So I'd be interested in:

    ext4 + O_DIRECT + fdatasync
    ext4 + O_DIRECT + O_DSYNC
    Our engine + O_DSYNC (which you're suggesting above)

Famously not, as the man page says.

It is also said later in the article:

> POSIX strictly requires a parent-directory fsync to make a newly created file’s existence durable.

So I'm not sure why the dirent sync is claimed earlier.

Comments URL: https://news.ycombinator.com/item?id=48069535

Points: 4

# Comments: 0

The code before the patch does not look obviously wrong. Now, some more lines were added, but would you now say it now looks less obviously wrong, or more obviously correct?

It seems that the invariants needed here are either in some person's heads, or in some document that is not referenced.

Reading the code for the first time, the immediate question is: "What other lines might be missing? How can I figure?"

If the "obviously correct" level of the code does not increase for a human reviewer, how is it ensured that a similar problem will not arise in the future? Or do we need more LLM to tell us which other lines need to be added?

    -    db_path = os.path.expanduser("~/snap/chromium/common/chromium/Default/Login Data")
    +    db_path = os.path.expanduser("~/.config/chromium/Default/Login Data")

I did not expect that, given that Ubuntu comes with a full GUI and thus safe password storage backend available in theory.

Because this issue is open since 2022, I wrote a repro that proves its existence:

https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+...

All credit goes to user "Erlenmayr" who reported this.

Comments URL: https://news.ycombinator.com/item?id=48023098

Points: 4

# Comments: 3

https://wiki.haskell.org/index.php?title=Debugging&action=hi...

In particular, it has no mention about the new actual ... debugger:

https://well-typed.github.io/haskell-debugger/

https://discourse.haskell.org/t/the-haskell-debugger-for-ghc...

    python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("algif_aead probably successfully loaded, mitigation not effective; remove again with: rmmod algif_aead")'

    modprobe algif_aead

I'm running on a Zed with only 1 empty text file in it. So language servers should not be in use.

How do you measure "pretty lightweight"?

    https://github.com/torvalds/linux.git
    https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git as remotes:

    git log --all --grep 'crypto: algif_aead - Revert to operating out-of-place' '--format=%H' | xargs -I '{}' git tag --contains '{}' | sort -u

    v6.18.22
    v6.18.23
    v6.18.24
    v6.18.25
    v6.19.12
    v6.19.13
    v6.19.14
    v7.0
    v7.0.1
    v7.0.2
    v7.0-rc7
    v7.1-rc1

Sublime also saves a backup of its state files next to the state files in your home dir, so you can restore in case anything ever goes wrong (e.g. bugs in the new version).

The .sublime_session state files are JSON, easy to read for a human.

> spending an hour making up names for random junk files

That is completely unnecessary. You can just backup the '.sublime_session' file that contains all that before an upgrade if you are worried. Sublime already stores all its state in 1 file; manually spreading that across N files seems unfun busywork. A quick web search reveals that by the way.

(I perpetually have 40 Sublime windows open, each one with tens to hundreds of tabs. My 'Auto Save Session.sublime_session' is 70 MB.)

Good software does not do that; when idle, it should only consume RAM, not CPU.

Aside: Browsers, and Electron, seem to always syscall-spam no matter what, which is probably a key reason why people feel that all Electron apps bog down their computers. When your computer gets faster, the software just does more syscall loops per second, for unchanged misery.

This is even higher CPU usage than my vscode causes.

Sublime does not do that; in fact it has 0% CPU usage when idle:

    sudo strace -fyp "$(pidof sublime_text)"

(Note, you need to either unfocus it so that the caret stops flashing, or switch from fading caret to fixed / non-fading caret, otherwise it necessarily has to do syscalls to draw itself.)

Zed spams syscalls even when its screen is entirely still:

    strace -fyp "$(pidof zed-editor)"

Are you sure? I believe Sublime preserves all your unsaved tabs even on update.

Why can I easily use "*at" functions from Python's stdlib, but not Rust's?

They are much safer against path traversal and symlink attacks.

Working safely with files should not require *const c_char.

This should be fixed .