...bah I was in a rush this morning.  So to answer your question yes the "chard" mount option should effectively change all writes into synchronous writes.

Theoretically "data=ordered" is good enough because CFS will retry failed requests due to node failure.

Since we're on this topic I've started reviewing the CFS code to see whether this is actually happening.


On Thu, Feb 4, 2010 at 9:42 AM, Roger Tsang <roger.tsang@gmail.com> wrote:
In OpenSSI unstable data is commited to backing storage on chard mounts.

On Thu, Feb 4, 2010 at 5:14 AM, John Hughes <john@calva.com> wrote:
In order to do filesystem failover we need to mount filesystems with the
"chard" flag, which ensures that on failover the backup node sees the
same filesystem state as the last one the primary node saw.  This is
necessary to avoid programs running on nodes other than the one that
crashed seeing unexpected filesystem changes during the failover.

As I understand it on Linux the chard flag effectively changes all
writes into synchronous writes.  Is this correct?

What effect would the "data=journal" ext3 mount option have?  In fact,
isn't it needed?

As I remember the UnixWare cfs implementation would attempt to reduce
the performance loss of "char" mounts by checkpointing writes to the
filesystem backup node rather than forcing them to disk.

Maybe we could obtain the same effect by writing our own version of the
Linux "jbd" (Journaling block device, http://kerneltrap.org/node/6741)
which would checkpoint stuff to another node, instead of to disk.  (We'd
still need to force real user requested sync data to disk though.)

Or maybe this is all nonsense.

The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
ssic-linux-devel mailing list