On Fri, Dec 17, 2010 at 1:38 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
