[rescue] SS10 HD bracket - now what is...

[James Lockwood]

On Thu, 30 May 2002 dave at cca.org wrote:

> But local processes aren't blocking on a disk write. Remote NFS

Of course they are.  Anything that invokes either a sync metadata commit
can block, or queued write that goes over the ufs throttle (I'm assuming
Solaris/ufs here).  Why do you think fastfs gives a boost when you are
doing heavy metadata updates?  Presto is a way of getting this kind of
performance without the same risk or corruption.

> There's a small advantage still, in that the buffers are being moved
> from main memory to battery backed memory, but that sort of thing
> is better solved through raid or journaled filesystems.

!

Journaling to disk (which is what I assume you are referring to here) can
be handy but is many orders of magnitude slower than journaling to NVRAM
(which is essentially what PrestoServe does).

Assume a common scenario, ufsrestore.  Sync metadata updates cannot be
batched as they are issued sequentially.  Each sync operation takes on the
order of 10ms (ok, 6ms with state of the art).  This means you are
fundamentally limited to 100 sync operations (example: inode
create/delete) per second.  This is _slow_.

RAID doesn't help with this.  No version of RAID by itself gives a magic
boost to write latency.  The only thing that does is caching to NVRAM,
which is exactly what PrestoServe does.

-James