zfs discuss - Jul 2007 - Take Three: PSARC 2007/171 ZFS Separate Intent Log

Hello,

This is a third request to open the materials of the PSARC case
2007/171 ZFS Separate Intent Log
I am not sure why two previous requests were completely ignored
(even when seconded by another community member).
In any case that is absolutely unaccepted practice.



On 6/30/07, Cyril Plisko <cyril.plisko at mountall.com>
wrote:
> Hello !
>
> I am adding zfs-discuss as it directly relevant to this community.
>
> On 6/23/07, Cyril Plisko <cyril.plisko at mountall.com> wrote:
> > Hi,
> >
> > can the materials of the above be open for the community ?
> >
> > --
> > Regards,
> >         Cyril
> >
>
>
> --
> Regards,
>         Cyril
>

-- 
Regards,
        Cyril

On 7/7/07, Cyril Plisko <cyril.plisko at mountall.com>
wrote:
> Hello,
>
> This is a third request to open the materials of the PSARC case
> 2007/171 ZFS Separate Intent Log
> I am not sure why two previous requests were completely ignored
> (even when seconded by another community member).
> In any case that is absolutely unaccepted practice.
The past week of inactivity is likely related to most of Sun in the US
being on mandatory vacation.  Sun typically shuts down for the week
that contains July 4 and (I think) the week between Christmas and Jan
1.

Mike
-- 
Mike Gerdts
http://mgerdts.blogspot.com/

>On 7/7/07, Cyril Plisko <cyril.plisko at mountall.com> wrote:
>> Hello,
>>
>> This is a third request to open the materials of the PSARC case
>> 2007/171 ZFS Separate Intent Log
>> I am not sure why two previous requests were completely ignored
>> (even when seconded by another community member).
>> In any case that is absolutely unaccepted practice.
>
>The past week of inactivity is likely related to most of Sun in the US
>being on mandatory vacation.  Sun typically shuts down for the week
>that contains July 4 and (I think) the week between Christmas and Jan
>1.
>

But not "mandatory" this year (but many appear to have arranged for 
vacation because of the 4th of July and because they half expected a
mandatory shutdown)

Casper

Cyril,

I wrote this case and implemented the project. My problem was
that I didn''t know what policy (if any) Sun has about publishing
ARC cases, and a mail log with a gazillion email addresses.

I did receive an answer to this this in the form:

http://www.opensolaris.org/os/community/arc/arc-faq/arc-publish-historical-checklist/

Never having done this it seems somewhat burdensome, and will take some time.

Sorry, for the slow response and lack of feedback. Are there
any particular questions you have about separate intent logs
that I can answer before I embark on the process?

Neil.

Cyril Plisko wrote:
> Hello,
> 
> This is a third request to open the materials of the PSARC case
> 2007/171 ZFS Separate Intent Log
> I am not sure why two previous requests were completely ignored
> (even when seconded by another community member).
> In any case that is absolutely unaccepted practice.
> 
> 
> 
> On 6/30/07, Cyril Plisko <cyril.plisko at mountall.com> wrote:
>> Hello !
>>
>> I am adding zfs-discuss as it directly relevant to this community.
>>
>> On 6/23/07, Cyril Plisko <cyril.plisko at mountall.com> wrote:
>>> Hi,
>>>
>>> can the materials of the above be open for the community ?
>>>
>>> --
>>> Regards,
>>>         Cyril
>>>
>>
>> --
>> Regards,
>>         Cyril
>>
> 
>

On 7/7/07, Neil Perrin <Neil.Perrin at sun.com>
wrote:
> Cyril,
>
> I wrote this case and implemented the project. My problem was
> that I didn''t know what policy (if any) Sun has about publishing
> ARC cases, and a mail log with a gazillion email addresses.
>
> I did receive an answer to this this in the form:
>
>
http://www.opensolaris.org/os/community/arc/arc-faq/arc-publish-historical-checklist/
>
> Never having done this it seems somewhat burdensome, and will take some
time.
Neil,

I am glad the message finally got through.

It seems to me that the URL above refers to the publishing
materials of *historical* cases. Do you think the case in hand
should be considered historical ?

Anyway, many ZFS related cases were openly reviewed from
the moment zero of their life, why this one was an exception ?
>
> Sorry, for the slow response and lack of feedback. Are there
> any particular questions you have about separate intent logs
> that I can answer before I embark on the process?
Well, that only question I have now is what is it all about ?
It is hard to ask question without access to case materials,
right ?

-- 
Regards,
        Cyril

Cyril Plisko wrote:
> On 7/7/07, Neil Perrin <Neil.Perrin at sun.com> wrote:
>> Cyril,
>>
>> I wrote this case and implemented the project. My problem was
>> that I didn''t know what policy (if any) Sun has about
publishing
>> ARC cases, and a mail log with a gazillion email addresses.
>>
>> I did receive an answer to this this in the form:
>>
>>
http://www.opensolaris.org/os/community/arc/arc-faq/arc-publish-historical-checklist/
>>
>>
>> Never having done this it seems somewhat burdensome, and will take 
>> some time.
> 
> Neil,
> 
> I am glad the message finally got through.
> 
> It seems to me that the URL above refers to the publishing
> materials of *historical* cases. Do you think the case in hand
> should be considered historical ?
Yes, this was what I was asked to do. Looking more closely it doesn''t
look
too bad. I''ll start this process.
> 
> Anyway, many ZFS related cases were openly reviewed from
> the moment zero of their life, why this one was an exception ?
There''s no good reason. Certainly the ideas had been kicked around
on the alias, but I agree there was no specific proposal and
call for discussion.
> 
>>
>> Sorry, for the slow response and lack of feedback. Are there
>> any particular questions you have about separate intent logs
>> that I can answer before I embark on the process?
> 
> Well, that only question I have now is what is it all about ?
> It is hard to ask question without access to case materials,
> right ?
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.

Hope this helps: Neil.

>> It seems to me that the URL above refers to the publishing
>> materials of *historical* cases. Do you think the case in hand
>> should be considered historical ?

In this context, historical means "any case that was not originally 
"open", and so can not be presumed to be clear of any proprietary
info.

For this particular case, I don''t expect there to be any such info,
so the process of opening it *should* be trivial - probably just 
changing any proprietary notices to Copyrights...
> 
> Yes, this was what I was asked to do. Looking more closely it
doesn''t look
> too bad. I''ll start this process.
once the case has been cleaned up and marked "open", it will be
mirrored
onto OS.o within 24 hours.


   -John

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.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: psarc_slog
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070709/810924fd/attachment.ksh>

Neil,

many thanks for publishing this doc - it is exactly
what I was looking for !


On 7/9/07, Neil Perrin <Neil.Perrin at sun.com>
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