Er with attachment this time.
So I've attached the accepted proposal. There was (as expected) not
much discussion of this case as it was considered an obvious extension.
The actual psarc case materials when opened will not have much more info
than this.
PSARC CASE: 2007/171 ZFS Separate Intent Log
SUMMARY:
This is a proposal to allow separate devices to be used
for the ZFS Intent Log (ZIL). The sole purpose of this is
performance. The devices can be disks, solid state drives,
nvram drives, or any device that presents a block interface.
PROBLEM:
The ZIL satisfies the synchronous requirements of POSIX.
For instance, databases often require their
transactions to be on stable storage on return from the system
call. NFS and other applications can also use fsync() to ensure
data stability. The speed of the ZIL is therefore essential in
determining the latency of writes for these critical applications.
Currently the ZIL is allocated dynamically from the pool.
It consists of a chain of varying block sizes which are
anchored in fixed objects. Blocks are sized to fit the
demand and will come from different metaslabs and thus
different areas of the disk. This causes more head movement.
Furthermore, the log blocks are freed as soon as the intent
log transaction (system call) is committed. So a swiss cheesing
effect can occur leading to pool fragmentation.
PROPOSED SOLUTION:
This proposal takes advantage of the greatly faster media speeds
of nvram, solid state disks, or even dedicated disks.
To this end, additional extensions to the zpool command
are defined:
zpool create <pool> <pool devices> log <log devices>
Creates a pool with a separate log. If more than one
log device is specified then writes are load-balanced
between devices. It's also possible to mirror log
devices. For example a log consisting of
two sets of two mirrors could be created thus:
zpool create <pool> <pool devices> \
log mirror c1t8d0 c1t9d0 mirror c1t10d0 c1t11d0
A raidz/raidz2 log is not supported
zpool add <pool> log <log devices>
Creates a separate log if it doesn't exist, or
adds extra devices if it does.
zpool remove <pool> <log devices>
Remove the log devices. If all log devices are removed
we revert to placing the log in the pool. Evacuating a
log is easily handled by ensuring all txgs are committed.
zpool replace <pool> <old log device> <new log device>
Replace old log device with new log device.
zpool attach <pool> <log device> <new log device>
Attaches a new log device to an existing log device. If
the existing device is not a mirror then a 2 way mirror
is created. If device is part of a two-way log mirror,
attaching new_device creates a three-way log mirror,
and so on.
zpool detach pool <log device>
Detaches a log device from a mirror.
zpool status
Additionally displays the log devices
zpool iostat
Additionally shows IO statistics for log devices.
zpool export/import
Will export and import the log devices.
When a separate log that is not mirrored fails then
logging will start using chained logs within the main pool.
The name "log" will become a reserved word. Attempts to create
a pool with the name "log" will fail with:
"cannot create 'log': name is reserved
pool name may have been omitted"
Hot spares cannot replace log devices.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
