Re: [concept & "good taste" review] persistent store

[Tony Luck <tony.luck@intel.com>]

On Fri, Dec 17, 2010 at 1:38 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> Yes. However, I still question the "filesystem" part.
>
> Technically, what I think any persistent storage should aim for is to
> be a "journal" - not a filesystem. It's most useful as a temporary
> area for data _before_ that data actually hits the disk, and once it
> has hit the disk (or has been picked up by a network syslog server, of
> course), the usefulness of the persistent storage immediately
> vanishes.
>
> So I don't really mind having a filesystem interface to that (the
> whole "everything is a file" model), but I think it can end up
> confusing people about what this thing is useful for. I fear that
> people will try to write to it from user space as some kind of
> mini-filesystem, and that seems pointless.

Do we have any good models for "journals" ... apart from
the console log?  Ying & I did talk about just using printk
to drop all the saved information onto the console (with
some sort of "previous" prefix on each line to make
it easy to find, and to make sure that someone glancing
at the messages wouldn't worry that that OOPs scrolling
by was happening now).  But this seemed like a really bad
idea (especially if someone has enough persistent store to
capture all of __logbuf).

So the downside of "everything is a file" is that we don't
have much infrastructure for things that don't look like
files - and trying to build some results in some special
custom tools being needed to access the data, which
just makes things harder to use.

People trying to write to /dev/pstore will figure out quickly
that you can't do that. There are no "ops" to make new files,
directories, symlinks or even to rename existing ones. You
can overwrite existing files (because I don't trap "open" to
deny them write access - but the 0444 mode is supposed
to be a visual clue to not do that).

-Tony