Re: Ridiculous idea: Cache as ramdisk?

[Chris Pressey <cpressey@xxxxxxxxxxxxxxx>]

On Tue, 23 Sep 2003 10:15:05 -0700 (PDT)
Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote:

> :Hm, my only suggestion is to abstract it just a little further - say
> :every file has a different "importance" - from (say) 0 for "not
> :important at all, I don't care if it suddenly disappears" to (say) 9
> for:"very important, make sure it's in NV storage ASAP"
> :
> :This way the behaviour isn't tied to any particular mechanism, and
> that:should theoretically make it easier for both implementers (who
> can use a:different mechanism, should it come down to that) and users
> (who don't:have to think in terms of "buffer cache" and other concepts
> they don't:necessarily understand well.)
> 
>     "Ick".  This brings non-deterministic behavior to a new level :-).
>     It may sound good on paper, but it will never work in practice
>     because in practice there are only two levels of importance:  (1)
>     You don't care if it goes away, or (2) It had better not go away.

OK, have only two levels, then - important and not important.  I don't
think that changes the thrust of my suggestion (i.e. don't describe it
at the mechanism level, describe it at the behaviour level.  Even if
it's only ever implemented in the buffer cache, at the very least the
end user doesn't have to think about it in those terms.)

> :Journalling file systems seem to be rather optimized for recovery, vs
> :the impression I get when I hear the word "journalling" - I think of
> :something more like CVS, where you can get any older version of a
> file:merely by requesting a different tag.  Such a "write once"
> filesystem:would be very nice to use, I think.
> :
> :Anyway... back to your regularly scheduled BSD forking...
> :
> :-Chris (in Vancouver, if you care)
> 
>     There are major advantages to being able to access a filesystem
>     as of some date in the past.  For example, it makes 'undelete'
>     work very precisely.  Another huge advantage to a properly
>     journaled filesystem is that one can run a continuously streaming
>     'incremental backup' of the filesystem as well as use such a
>     stream to maintain a fully independant off-site copy of the
>     filesystem in near real time.

I agree completely; the thing is, I'm not sure I've ever seen a
filesystem that describes itself as "journalling" that does anything
remotely like this :)  The "journalling" seems to always be an internal
feature provided to make data recovery less painful - rather than
something the user can access directly, to "rollback" to old versions of
their files, like CVS.  (Which, to me, is what "journalling" means...)

i.e. from their overviews, the emphasis is clear:

JFS: "JFS provides fast file system restart in the event of a system
crash."
XFS: "The XFS journaling technology allows it to restart very quickly
after an unexpected interruption, regardless of the number of files it
is managing."
ext3: "By contrast, ext3 does not require a file system check, even
after an unclean system shutdown, except for certain rare hardware
failure cases (e.g. hard drive failures)."

I guess what I'm wondering is, does anyone here know of a journalling
file system out there that *isn't* just for speeding up data recovery?

-Chris