[Wp-mirror-list] Fresh Debian Wheezy install fails on 'nil' and hdparm

[wp mirror]

Dear Jason,

1) Durability

There is a trade-off between the Durability (the `D' in `ACID') of
committed database transactions and database performance.  Most
hard-disk drives have an electronic write cache which may be enabled
(default) or disabled.  When the HDD write cache is enabled, disk
writes are cached and then written out-of-order to the magnetic media
using something like an elevator algorithm. When the HDD write cache
is disabled, disk writes go directly to the magnetic media.

While enabling HDD write cache improves performance, there is a risk.
Database transactions that you might think are committed, turn out to
reside in the HDD write cache for a period of time before being
written to magnetic media.  This means that if the power fails (for
example) those transactions are lost.  For full ACID compliance, the
HDD that stores your database should have its HDD write cache
disabled.

For other reasons, wp-mirror uses check-pointing.  Consequently, if
the HDD write cache is enabled (default) and the power fails, that
should not be a tragedy.  For the next time you run wp-mirror, it will
resume from the last known check-point and therefore repeat any lost
transactions.

I believe the user should have the option of deciding how to configure
the HDD write cache.

2) hdparm

The utility `hdparm' lets you determine the state of your HDD write
cache using a command like:

(root-shell)# hdparm -W /dev/sda

/dev/sda:
 write-caching =  1 (on)
(root-shell)#

You can disable or enable the HDD write cache with commands like:

(root-shell)# hdparm -W0 /dev/sda
(root-shell)# hdparm -W1 /dev/sda

respectively.

3) wp-mirror

Wp-mirror identifies the physical drive on which the database base is
stored.  Since block devices are often mapped, this is done by chasing
slaves through the `/sys' directory like so:
/sys/block/<dev>/slaves/<dev>/slaves/...' until an empty `slaves'
directory is encountered.

When the physical HDD has been determined, wp-mirror determines the
state of the HDD write cache by parsing the output of

(root-shell)# hdparm -W <physical partition>

and then either enables (default) or disables it.

As mentioned above, wp-mirror uses check-pointing.  To ensure that all
committed transactions preceding each check-point are durably
committed to magnetic media, wp-mirror flushes the HDD write cache by
executing a command like:

(root-shell)# hdparm -F /dev/sda

4) /bin/true

Your suggested hack is interesting but does not generate the output
expected by wp-mirror.  In other words, wp-mirror fails to parse the
non-existent output.  Hence the error message.

5) kvm

It would help me very much if you could log into your virtual machine,
execute the following command:

(root-shell)# hdparm -W /dev/vda2

and send me the output.  An important design objective for wp-mirror
is that it should work `out-of-the-box' with no user configuration.
Clearly this did not happen for your configuration, and I would like
to fix that.

6) Documentation

The documentation for wp-mirror can be found under
`/usr/share/doc/wp-mirror/doc/'.  You can use the command:

(shell)$ xpdf /usr/share/doc/wp-mirror/doc/wp-mirror-0.6.pdf.gz

It includes a discussion of `hdparm' (see section 3.2.1 Plan Your Disk
Space).  More importantly, it includes the results of performance
trials (see appendix G.3 fsm-file-import and Durability).

Sincerely Yours,
Kent

Date: Sun, 8 Dec 2013 16:48:20 -0500
From: Jason Cooper <address@hidden>
To: address@hidden
Subject: Fresh Debian Wheezy install fails on 'nil' and hdparm

All,

I just learned about wp-mirror yesterday, so forgive me if this is a
naive question.

I just did a clean install of Debian Wheezy to a VM with ~200G.  My
first problem is that 'wp-mirror --mirror' insists on running hdparm on
the root LV, which is backed by /dev/vda2...  I worked around this by
setting:

(defparameter *whereis-hdparm*               "/bin/true")

in local.conf.  I don't think this is the proper way to disable this
option and I'd appreciate some suggestions.  Honestly, I've never seen a
config file format like this before...

The second problem is that in working around hdparm, I then get:

-----asserting-prerequisite-hardware-begin----
[ ok ]count-cpu
[ ok ]assert-disk-space-if-large-wikipedia-p
[ ok ]assert-physical-memory-if-large-wikipedia-p
[ ok ]assert-partition-free-images
[....]assert-hdd-write-cache-p
*** - regexp:regexp-exec: argument nil is not a string

based on it's use in default.conf, I assume that nil is legitimate
syntax, so something else must be wrong.  Any idea what could be wrong
here?  I suspect that this is fallout from my first hack, but I can't be
sure.

thx,

Jason.