Hacker News Reader

Comment by heavenlyblue | Hacker News Reader

Your example would fail to accommodate the most basic application of files: logging and reading file logs at the same time.

View on HN

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.

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.

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?

It already exists in the form of databases.

First that comes to mind is etcd.

Where do you plan to store the logs then?

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

That's handled by point 6. You would be able to have shared ownership of the log files, but you wouldn't be able to just write to it willy-nilly. In this case, the specialized application would be trivial because it would just need to ensure that writes are append-only.

> Applications can provide the ability for shared ownership, but those would by specialized applications capable of handling and merging simultaneous changes.

Agreed.

Surely my logging application would "own" the read-write handle, while my tail application merely "borrowed" a handle for read-only.

How do those semantics differ from multi-writers which can all write in transactional blocks?

Reply on news.ycombinator.com