So it is with the family of mutually incomprehensible ISAs called RISC-V.

> When did this become a discussion limited to journald on btrfs?

btrfs is in the HN thread title.

> and that seems like something btrfs should fix at some point

Amazing. The Linux kernel should change to work around journald's inflexibility?

What someone should fix at some point is journald's strange IO patterns and hard-coded "helpful" attribute changes. I'd rather it just rename the file and let me do any defrag/compression/flag-setting I want than do anything with chattr behind my back in ways I can't even configure.

Clearing FS_NOCOW_FL doesn't work on btrfs for non-empty files. So what do you think journald is doing when it notices that it can't clear the flag?

https://github.com/systemd/systemd/blob/8f4cd7de43d1e6e94687...

WAL writeback is at least principled and efficient. It works out to being equivalent to the custom Parquet-rotation things others mention, but already implemented and working.

So, yes, WAL for logs, because LSM is the design everyone converges on and a WAL is LSM. Better to use the LSM already implemented and debugged in a database than write some random new one in terms of Parquet that's going to have to do the same stuff in the end anyway, just with novel bugs and no tool support.

(And look, I don't give a damn what "DB" people say, a WAL writing back to a DB IS log... structured... merge under any fucking sensible definition of what LSM means.)

Forget about DB terminology and look at what's happening ON THE DISK. ON THE DISK, is what DuckDB doing any less efficient than what your custom Parquet thing would be doing?

Your LSM compaction strategy is going to have to solve the same problem anyway, isn't it? DuckDB is an LSM compaction strategy of this form, already done.

You're getting COW on the extents if you're snapshotting anyway.

We shouldn't be making momentus choices of data format based on vague and incorrect understandings of data formats.

> If you write a few bytes into some arbitrary position within a file, the storage has to write back the whole block, despite your only changing a tiny fraction of it. If those few bytes happened to cross a block boundary, guess what? two blocks get written.

Exactly. So either make the format append-only or make it append-mostly with occasional writebacks from the append-only log to the main data structure. Nice and simple.

> I'd expect the mmap aspect to be causing more/mispredicted reads, and polluting the page cache with unrelated contents (you tend to end up with the entire journal cached IIRC, if you have enough memory).

If you used an LSM or append-only approach, you could MADV_DONTNEED the pages behind your write cursor pretty easily.

"But isn't it an OLAP database? Shouldn't you use SQLite for something that's vaguely real-time?"

Eh, in this instance, I think I'd prefer the columnar design and automatic compression DuckDB affords. Log entries have lots of little fields, many of which are unchanging from row-to-row, and DuckDB excels at storing this kind of data.

BTW: no, you don't need O(N*log(N) writes for DuckDB. No, you're not doing a whole block-group write for every message. No, Parquet is not a magical solution. I mean, maybe it's fine, but DuckDB is already columnar, and arguably better at it.

Seems like there are a lot of mistaken impressions about DB storage engines out there.

Damn. Now my artist-mode in Emacs skills are useless.

My real problem with Electron is the multi-process render architecture, which I think is pointless for the "just a GUI toolkit" case of rendering only trusted content. I'm 100% fine with Slack, Spotify, whatever using Electron as their choice of GUI toolkits. These come and go. I'm miffed that they use multiple processes when there's no real security boundary between them just because there is a security boundary in the homologous scenario on the web.