5 ms·

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

satyenr 7y ago
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.
- mchristen 7y ago
  Where do you plan to store the logs then?
  - satyenr 7y ago
    On the disk, as usual. Files are, after all, an interface.
- heavenlyblue 7y ago
  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.
  - satyenr 7y ago
    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?
    - heavenlyblue 7y ago
      It already exists in the form of databases. First that comes to mind is etcd.
- walterstucco 7y ago
  Like windows does with the event store? Naaahhhh thanks
TheCoelacanth 7y ago
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.
- satyenr 7y ago
  Agreed.
jbreckmckye 7y ago
Surely my logging application would "own" the read-write handle, while my tail application merely "borrowed" a handle for read-only.
- heavenlyblue 7y ago
  How do those semantics differ from multi-writers which can all write in transactional blocks?

satyenr 7y ago

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.

mchristen 7y ago
Where do you plan to store the logs then?
- satyenr 7y ago
  On the disk, as usual. Files are, after all, an interface.
heavenlyblue 7y ago
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.
- satyenr 7y ago
  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?
  - heavenlyblue 7y ago
    It already exists in the form of databases. First that comes to mind is etcd.
walterstucco 7y ago
Like windows does with the event store? Naaahhhh thanks

TheCoelacanth 7y ago

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.

satyenr 7y ago
Agreed.

jbreckmckye 7y ago

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

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