Garrett D'Amore wrote:
> In my opinion it pushes the boundaries of what is appropriate for a
> self-review, since this represents a potentially significant new
> behavior that will be exposed to customers and ISVs.
>
> However, it also looks fairly obvious and straight-forward.
>
> Can I kindly request that you promote this to a fast track, and accept
> my +1 at the same time?
>
> (Unless someone else has some significant concern, the only negative
> implication of this is that you'll need to wait a few days before
> integrating ... probably this will be approved on Wednesday.)
>
> - Garrett
>
Sure. I've changed the IAM file and set the timeout for 8/14.
-tim
> Tim Haley wrote:
>> I am sponsoring the following case on behalf of Neil Perrin.
>> Requested binding is Micro/Patch. The case is a straight-forward
>> addition of a new property on zfs datasets for tuning separate
>> intent log usage. I believe the case qualifies for self review and
>> have filed it as closed approved automatic. If folks disagree, let me
>> know and I'll convert it to a fast-track.
>>
>> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
>> This information is Copyright 2009 Sun Microsystems
>> 1. Introduction
>> 1.1. Project/Component Working Name:
>> ZFS logbias property
>> 1.2. Name of Document Author/Supplier:
>> Author: Neil Perrin
>> 1.3 Date of This Document:
>> 07 August, 2009
>>
>> 4. Technical Description
>>
>> Summary
>>
>> Provide zfs with the ability to control the use of resources
>> used for synchronous (eg fsync, O_DSYNC) requests. In particular
>> it enables substantially better performance for Oracle and
>> potentially other applications.
>>
>> Background
>>
>> Oracle manages two major types of files, the Data Files and the Redo Log
>> files. Writes to Redo Log files are in the path of all transactions
>> and low latency is a requirement. It is critical for good performance
>> to give high priority to these write requests.
>>
>> Data Files are also the subject of writes from DB writers as a form of
>> scrubbing dirty blocks to insure DB buffer availability. Write latency is
>> much less an issue. Of more more importance is achieving an acceptable
>> level
>> of throughput. These writes are less critical to delivered performance.
>>
>> Both types of writes are synchronous (using O_DSYNC), and thus treated
>> equally. They compete for the same resources: separate intent log,
>> memory, and normal pool IO. The Data File writes impede the potential
>> performance of the critical Redo Log writers.
>>
>> Proposal
>>
>> Create a new "logbias" property for zfs datasets.
>>
>> If logbias is set to 'latency' (the default) then there is no change
>> from the
>> current implementation. If the logbias property is set to 'throughput'
>> then intent log blocks will be allocated from the main pool instead of
>> any
>> separate intent log devices (if present). Also data will be written
>> immediately to spread the write load thus making for quicker subsequent
>> transaction group commits to the pool.
>>
>> To change the property, an admin will use the standard zfs set command:
>>
>> # zfs set logbias=latency {dataset}
>> # zfs set logbias=throughput {dataset}
>>
>> The current value of logbias can be retrieved in the normal
>> manner with 'zfs get logbias' or 'zfs list -o logbias'.
>>
>> Manpage diffs
>>
>> --- old=09Thu May 7 15:41:08 2009
>> +++ new=09Thu May 7 15:44:30 2009
>> @@ -1038,7 +1038,15 @@
>> perty was changed. If the new property is "off", the
>> file systems are unshared.
>>
>> + logbias = latency | throughput
>> +
>> + Provide a hint to ZFS about handling of synchronous
>> + requests in this dataset. If logging is set to "latency" (the
>> + default) ZFS will use pool log devices (if configured) to handle the
>> + requests at low latency. If logging is set to "throughput" then ZFS
>> + will not use configured pool log devices. ZFS will
>> + instead optimize synchronous operations for global
>> + pool throughput and efficient use of resources.
>>
>> 6. Resources and Schedule
>> 6.4. Steering Committee requested information
>> 6.4.1. Consolidation C-team Name:
>> ON
>> 6.5. ARC review type: Automatic
>> 6.6. ARC Exposure: open
>>
>>
>
