On Sun, Mar 25, 2007 at 06:49:35PM +0000, Simon Truss
wrote:
> Thor Lancelot Simon wrote:
> >On Sun, Mar 25, 2007 at 10:24:34AM +0000, Simon
Truss wrote:
> >>Hi,
> >>
> >>From the recent SOC discussion I gather that
the advantage of
> >>journalling over softdep is the fast replay of
the journal obviating the
> >>need to fsck the whole disk. My thinking here
is that softdep and
> >>journalling has been kept as independent
strategies and that a combined
> >>softdep+journal may prove slightly simpler and
more efficient than a
> >>full blown independent journal solution.
> >
> >I think it's about the same amount of work. You're
right, as far as I
> >can tell, that it should be possible to use softdep
to order the writes
> >for the filesystem, then output those ordered
writes into a journal. It
> >would be nice if softdep in fact were a generic
layer that produced an
> >ordered graph of the writes for a chunk of the
filesystem namespace.
>
> Are we saying then that there is a commonality in
required fs hooks
> between journalling and softdep. That by developing
journalling and some
> clean dependency hooks there might come a time when
softdep can be moved
> over to this common interface? That would be wonderful,
both progress
> and practical.
That won't work.
The idea behind jopurnaling in this context is journaling as
used in data
bases. Either an operation on the fs metadata has happened
or it hasn't; a
change is atomic. Thus you have either created a file or you
haven't. You
have deleted a file or you haven't.
To achieve that, you have to perform two sets of writes. You
first write
an operation into the journal. If something happens before
that write
completes, the event hasn't happened. Once the write's in
the journal, the
event has happened, and so we write all the blocks onto the
disk. We don't
delete the entry from the journal (we don't let the journal
over write it)
until all the other writes are done.
One consequence is that the write ordering is "write
the journal" "write
everything else". So the ordering model is very
different from the normal
one. Soft updates doesn't change the write ordering model,
it just makes
it much more asynchronous compared to the caller.
So mixing them won't really work.
Note that while a journal can help with a lot, there are
things it can't
do. For instance, if you have a bug in a driver or in the fs
code itself,
the journal won't save you. Likewise a double fault on a
RAID 5 is deadly.
Also, if caching is turned on on a disk and we don't have
something akin
to FUA (Force Unit Access) (or if we assert FUA and the
device lies to us
about completion), then we can have a huge safety issue; we
depend on
being able to know that the journal write has finished
before moving on.
> I have just about reached by limit of my file system
knowledge, should I
> continue into detail with this concept I will be
proceeding to fantasy
> systems instead 
>
> >But it's not. Instead, it's a huge mess of
spaghetti code that is
> >incestuous with all layers of the FFS
implementation at every opportunity.
>
> Yikes. That's a good reason not to mess with softdep.
Practicality
> always gets in the way.
>
> >From my point of view one major advantage of a
journalled FFS would be
> >the simplicity it would bring back to our core
filesystem implementation.
> >I would be very happy to get good filesystem
performance from kernels
> >that didn't have the softdep code anywhere near
them.
>
> agreed, but softdep in concept still has a lot of
potential, some of
> which cannot be offered by journalling. I would hope
that if softdep was
> removed that something could be found to take its place
some day.
Other than the fact that the need for writes can disapear
(consider
creation of a temporary file that then gets deleted before
the update
flushes to disk), what potential did you have in mind?
Take care,
Bill
|
netbsd.org> wrote:
> Also, if caching is turned on on a disk and we don't
have something akin
> to FUA (Force Unit Access) (or if we assert FUA and the
device lies to us
> about completion), then we can have a huge safety
issue; we depend on
> being able to know that the journal write has finished
before moving on.
What devices lie about this? Is there some info I can read
somewhere
about this problem?
I turn off IDE disk write caching on all my disks at boot
time, and I
was hoping that would help me. I've been bitten hard by
write caching
before.
Andy