On Monday, February 5, 2001, at 06:48 PM, Artur Grabowski wrote:

> "Peter Galbavy" <peter.galbavyknowledge.com> writes:
>
> > > Soft Updates use magically delicious write ordering to provide the same
> > kind of
> > > metadata integrity protection as a journaling filesystem, but without any
> > > changes to the underlying filesystem structure. Soft Update support is
> > pretty
> > > stable in OpenBSD 2.8. As long as
> >
> > With the greatest of respect, let me refer the gentlemen to the word
> > "bollocks".
> >
> > Sorry, I felt like being frivolous. In reality, softupdates to not provide
> > the most important part of a journaling file system, next to ordered writes,
> > and that is zero-integrity checking at boot.
> >
> > One of the major benefits, especially as file systems are getting into the
> > terabyte ranges now, is that if there is some catastophic failure (outside
> > the file system code) like power or memory fault, then the file system will
> > come back clean very quickly - with a log of the writes that can be applied
> > in order *if* they are marked as complete.
> >
> > Maybe I am misunderstanding journaling file systems, but those are the two
> > features that I expect to see (fast writes and not fsck).
>
> soft updates do not provide "fast" fsck yet. But they are designed to be
> able to do that. It's just a matter of writing the code (or rather, it's a
> matter to wait for Kirk McKusick to write the code and import it to OpenBSD
> at a later time).

Yup, softupdates really speeds the disk accesses when doing such things as compiling, cvs updating, database operations or huge file moves, especially when lots of write are involved.
But beware of not being caught by a crash at that time (and it happens quite easily on sustained writes), in that case, on reboot, you will have a long fsck stage and will loose almost all the files supposed to have been written !!!

It's like softupdates, while reordering the writes, caches to the max all the disk operations, filling up the available physical memory up to the point of swapping (remember those crashes with < 32M and softupdates enabled ?) ; usually 'lockmgr' was involved...

This is probably a bad analysis of the facts, but I don't know the kernel's intricaties, less disk I/O... Blame me if needed, but it happened to me ;-)

TYA,

  Thierry

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]