by rottegift » Thu Jul 10, 2014 5:06 am
log vdevs are only read at pool import time, otherwise (if they exist) they are write-only.
What gets written to the log vdev is the "intent" to commit a given block of synchronous data to the correct part of a pool. Synchronous data is generated by the fsync(2) system call or its equivalents, by some processes involved in serving up filesystems to network clients, and by some activities involving directory manipulation. Except for file servers that receive a lot of synchronous write requests from network (as an example, all NFS writes are synchronous writes), synchronous writes are typically sporadic and rare. On spinning disks, individual writes may take a significant amount of time to commit to a pool, and the in-pool intents log (i.e., writing the log into the primary storage vdevs) is usually faster by avoiding some of the work involved in committing writes while still allowing a synchronous write call to return.
Logging into the primary storage vdevs can still be slow, especially on busy pools, because of underlying latencies, notably the time to move a disk's read-write head from one track to another. A separated log ("slog") that is doing nothing other than receiving intent writes is likely to allow synchronous write calls to return much faster, and will also reduce IOPS pressure on the primary storage devices. Because they only take sequential writes and are read only at import time, all sorts of devices make suitable slogs. A standalone fast spinning disk can in some cases be a better choice for a slog than a slow solid state device. (In practice a slog will short-stroke a dedicated spinning disk).
When a log vdev becomes faulty while the pool is imported, intents are logged into the primary pool storage instead.
If a log vdev is configured and is entirely unavailable (missing, faulty, etc.) at import time then zpool import will fail with a helpful error message.
If a log vdev is available but simply degraded (e.g. only one device in a mirrored log vdev is unavailable) the pool will import in DEGRADED state, and zpool status -vx will give a helpful error message.
If you choose to use the "-m" flag to import a pool with an entirely unavailable log vdev, in the worst case you will lose whatever synchronous writes that were written to the log vdev but not committed to the pool's primary storage. You will still have a fully consistent pool, but userland tools that rely upon synchronous write semantics may have problems; database inconsistency is a common issue and may require manual intervention. The best case is that there was no synchronous data in the log vdev to be lost, and that is fairly common (e.g. it is always the case if the pool was cleanly exported, and many workloads only rarely make synchronous writes). Unfortunately ZFS cannot tell that a wholly unavailable log vdev contains no data. The upper bound on data loss is proportional to the size of the log vdev and the length of time between transaction group commits.