Neil,
many thanks for publishing this doc - it is exactly
what I was looking for !
On 7/9/07, Neil Perrin <[EMAIL PROTECTED]> wrote:
> 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.
>
>
>
--
Regards,
Cyril
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
