Rethinking the filesystem as global mutable state, the root of all evil

Re:Rethinking the filesystem as global mutable state, the ro... by satyenr on Tuesday June 11, 2019 @12:20PM (#20156832)

Who says logs have to be written to a file — at least as far as the user is concerned? Logs are a series of events — a LogStore will let you read events as they are appended. And even if you do want to store logs in “files”, the solution proposed here here let’s you borrow them for the owning application.

[ Parent | on HN ]

Re:Rethinking the filesystem as global mutable state, the ro... by heavenlyblue on Tuesday June 11, 2019 @01:47PM (#20157719)

My question goes more like this: “why the hell do you want to re-approach the idea of a filesystem if the new approach can’t even accommodate something as simple as storing log files?”.

It may be time for something completely different. Just stop calling it a filesystem.

[ Parent | on HN ]

Re:Rethinking the filesystem as global mutable state, the ro... by satyenr on Tuesday June 11, 2019 @03:02PM (#20158463)

Again, why do you care about files? Logs have nothing to do with files. Files are just the interface used by filesystem to show the event stream that is logs so you can use file based tools to access the.

I am not calling it a filesystem. Let’s call it a data bank?

[ Parent | on HN ]

Re:Rethinking the filesystem as global mutable state, the ro... by heavenlyblue on Tuesday June 11, 2019 @04:59PM (#20159487)

It already exists in the form of databases.

First that comes to mind is etcd.

[ Parent | on HN ]

Re:Rethinking the filesystem as global mutable state, the ro... by mchristen on Tuesday June 11, 2019 @01:36PM (#20157597)

Where do you plan to store the logs then?

[ Parent | on HN ]

Re:Rethinking the filesystem as global mutable state, the ro... by satyenr on Tuesday June 11, 2019 @03:03PM (#20158467)

On the disk, as usual. Files are, after all, an interface.

[ Parent | on HN ]