3 ms·

I think the BeTree operation model is simpler than the BeTree based file system. It might be better to use a BeTree database directly.

• derefr 5y ago
  Yeah, that's true. Analogous to using LMDB/BoltDB, directly instead of using Btrfs. And I guess, as long as the BeTree library could understand the concept of a non-expandable database file, you could just point it directly at a raw block device as its "database file" and it would be happy. The only concern I'd have in this case is that userspace database libraries usually don't worry about the possibility of interrupted partial-block writes, since they're usually writing to files on a filesystem, and the filesystem usually handles that possibility for them; while the filesystem itself — or a library working with a raw direct-write block device — does have to worry about partial-block writes. I think, in the case of raw "everything is a tree" storage (B-tree or Be-tree), you'd only need to ensure that 1. there's a journal for root-node-page offsets, and that 2. there's a separate freelist for root-node pages, not hanging off of the root node, but rather attached to the journal; such that root-node pages are only freed for overwrite once the journal entry for the new page is guaranteed flushed to disk. Of course, if you were lazy, you could get the semantics of a journal and rootnode-freelist, by making this database library write its root-node pages as regular sequence-numbered files in a directory backed by a real filesystem, relying on the real filesystem to declare those files fsync(2)'ed before it's willing to delete previous root-node-page files; and then considering the effective freelist to consist only of the intersection of the freelists from all currently-visible root-node-page files.