Daniel Phillips wrote:
> Um, this isn't the only place where support for dumb filesystems messes
> things up for smart filesystems, it's just the most painful. Dumb
> filesystems should have the right to remain dumb, but smart filesystems
> should pay a price for that. It would be so easy to fix this right now,
> why don't we?
>
> Of course, "right now" == 2.5, not 2.4.
On a slightly longer-term topic:
Has there every been any discussion of a general write-ahead enforcement
mechanism for Linux?
I'm thinking along these lines--
A program (resource manager) would attach an open file to a log manager.
Any write to the file would also cause a log record write, which returns a
strictly increasing log sequence number. That number is associated with
each
page in the cache.
Before writing any page to disc, the file system would check to see
whether the
page's LSN is <= secure LSN for the log manager of that page's file.
For file systems that support this, it would require
(1) A way to attach a file to a log manager (ioctl or ...)
(2) A log manager handle associated with each open file
(3) Some way to associate an LSN with a write()
(4) A place to store the LSN for each page in memory
(5) A way to check the highest secure LSN for the log manager
The log manager might well be writing the log data across a network, rather
than or in addition to writing it to disk (and it may be on a different file
system from the data file).
The advantages I see are that database systems and other resource managers
would have much less complicated buffering logic, that the data would not be
double-buffered, that the LRU algorithm would be more accurate (there was a
discussion of this a few months ago with regard to multiple file systems).
Hopefully we could better performance without having to tune so much.
It would also be a step toward a common open-source transaction manager.
There are issues with regard to checkpointing, but other than that, what do
you think of this idea?
A good/bad idea in general?
A good idea but the implementation ... ?
Yeah, right, try getting these FS implementers to agree. ?
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
