Comment by ghaff
2 years ago
There's an argument for copy-on-write filesystem options but it's pretty hard to argue there needs to be more than 2 or 3 "traditional" journaling filesystems like maybe ext4 and XFS.
2 years ago
There's an argument for copy-on-write filesystem options but it's pretty hard to argue there needs to be more than 2 or 3 "traditional" journaling filesystems like maybe ext4 and XFS.
His letter contends that ReiserFS was intended to be more than just a filesystem, and that jibes with what he was saying about it at the time. I think that it was meant to be a queryable database that happened to be good at implementing traditional filesystem semantics, but also optimally useful through some other kind of API.
Only 5-10 years after BeFS.
Can you explain what that means? What are 'traditional filesystem semantics' and how would it be useful through 'some other kind of API'?
Well, you know how to R/W data with a normal filesystem. You can chdir() to the location you want to be, look around there with readdir(), open() and read() or write() files in there, and all that.
You could also have a SQL-like API where could "select count(1) from all_files where path_root = '/usr' and owner_uid = 0 and world_readable = true" that allowed you to query files, or maybe kernel calls that looked a lot like the Amazon S3 API (PutObject, ListObjects, ListBuckets, etc.) if that turns out to be more efficient for certain usecases.
The normal POSIX filesystem calls are obviously enormously useful. I mean, they've been used to implement SQLite and PostgreSQL, so you can* implement those other kinds of APIs on top of it. I can also imagine it being the case where there might be a much more efficient way to implement specific workflows if you didn't care about all the conventions that POSIX brings along.
1 reply →
I beg to differ. In 2024 we know that COW is bad regardless of whether we're talking about disk or memory.