zfs discuss - Jul 2012 - ZIL devices and fragmentation

Hello, list

   For several times now I''ve seen statements on this list implying
that a dedicated ZIL/SLOG device catching sync writes for the log,
also allows for more streamlined writes to the pool during normal
healthy TXG syncs, than is the case with the default ZIL located
within the pool.

   Is this understanding correct? Does it apply to any generic writes,
or only to sync-heavy scenarios like databases or NFS servers?

Thanks,
//Jim Klimov

On Jul 29, 2012, at 7:07 AM, Jim Klimov wrote:
> Hello, list
> 
>  For several times now I''ve seen statements on this list implying
> that a dedicated ZIL/SLOG device catching sync writes for the log,
> also allows for more streamlined writes to the pool during normal
> healthy TXG syncs, than is the case with the default ZIL located
> within the pool.
I''m not sure where you are heading here. Space for the data in the
pool is allocated based on the policies of the pool.
>  Is this understanding correct? Does it apply to any generic writes,
> or only to sync-heavy scenarios like databases or NFS servers?

Async writes don''t use the ZIL.
 -- richard

--
ZFS Performance and Training
Richard.Elling at RichardElling.com
+1-760-896-4422







-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20120729/dd8edc94/attachment.html>

On 07/29/2012 04:07 PM, Jim Klimov wrote:
> Hello, list
Hi Jim,
>   For several times now I''ve seen statements on this list implying
> that a dedicated ZIL/SLOG device catching sync writes for the log,
> also allows for more streamlined writes to the pool during normal
> healthy TXG syncs, than is the case with the default ZIL located
> within the pool.
> 
>   Is this understanding correct? Does it apply to any generic writes,
> or only to sync-heavy scenarios like databases or NFS servers?
Yes, it is correct. It applies to all writes. If the log is allocated on
a slog devices, then the synchronous log records don''t fragment the
pool. As far as I understand it, txgs happen sequentially even with no
slog device present, but the log entries don''t - they occur as is
needed
to fulfill the sync write request with minimum latency.

Cheers,
--
Saso

2012-07-29 19:50, Sa?o Kiselkov wrote:
> On 07/29/2012 04:07 PM, Jim Klimov wrote:
>>    For several times now I''ve seen statements on this list
implying
>> that a dedicated ZIL/SLOG device catching sync writes for the log,
>> also allows for more streamlined writes to the pool during normal
>> healthy TXG syncs, than is the case with the default ZIL located
>> within the pool.
>>
>>    Is this understanding correct? Does it apply to any generic writes,
>> or only to sync-heavy scenarios like databases or NFS servers?
>
> Yes, it is correct. It applies to all writes. If the log is allocated on
> a slog devices, then the synchronous log records don''t fragment
the
> pool. As far as I understand it, txgs happen sequentially even with no
> slog device present, but the log entries don''t - they occur as is
needed
> to fulfill the sync write request with minimum latency.
Thanks, I thought similarly, but the persistent on-list mention
(or words that could be interpreted that way) that with SLOG
devices writes ought to be better coalesced and less fragmented,
I started getting confused. :)

So, I guess, if the sync-write proportion on a particular system
is negligible (and that can be measured with dtrace scripts),
then a slog won''t help much with fragmentation of generic async
writes, right?

//Jim

On 07/29/2012 06:01 PM, Jim Klimov wrote:
> 2012-07-29 19:50, Sa?o Kiselkov wrote:
>> On 07/29/2012 04:07 PM, Jim Klimov wrote:
>>>    For several times now I''ve seen statements on this list
implying
>>> that a dedicated ZIL/SLOG device catching sync writes for the log,
>>> also allows for more streamlined writes to the pool during normal
>>> healthy TXG syncs, than is the case with the default ZIL located
>>> within the pool.
>>>
>>>    Is this understanding correct? Does it apply to any generic
writes,
>>> or only to sync-heavy scenarios like databases or NFS servers?
>>
>> Yes, it is correct. It applies to all writes. If the log is allocated
on
>> a slog devices, then the synchronous log records don''t
fragment the
>> pool. As far as I understand it, txgs happen sequentially even with no
>> slog device present, but the log entries don''t - they occur as
is needed
>> to fulfill the sync write request with minimum latency.
> 
> Thanks, I thought similarly, but the persistent on-list mention
> (or words that could be interpreted that way) that with SLOG
> devices writes ought to be better coalesced and less fragmented,
> I started getting confused. :)
> 
> So, I guess, if the sync-write proportion on a particular system
> is negligible (and that can be measured with dtrace scripts),
> then a slog won''t help much with fragmentation of generic async
> writes, right?
Correct.

Cheers,
--
Saso

On Sun, 29 Jul 2012, Jim Klimov wrote:
>  For several times now I''ve seen statements on this list implying
> that a dedicated ZIL/SLOG device catching sync writes for the log,
> also allows for more streamlined writes to the pool during normal
> healthy TXG syncs, than is the case with the default ZIL located
> within the pool.
After reading what some others have posted, I should remind that zfs 
always has a ZIL (unless it is specifically disabled for testing). 
If it does not have a dedicated ZIL, then it uses the disks in the 
main pool to construct the ZIL.  Dedicating a device to the ZIL should 
not improve the pool storage layout because the pool already had a 
ZIL.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-
> bounces at opensolaris.org] On Behalf Of Jim Klimov
> 
>    For several times now I''ve seen statements on this list
implying
> that a dedicated ZIL/SLOG device catching sync writes for the log,
> also allows for more streamlined writes to the pool during normal
> healthy TXG syncs, than is the case with the default ZIL located
> within the pool.
It might just be more clear, if it''s stated differently:

At any given time, your pool is in one of four states:  idle, reading, writing,
or idle with writes queued but not currently being written.  Now a sync write
operation takes place.  If you have a dedicated log, it goes directly to the
log, and it doesn''t interfere with any of the other operations that
might be occurring right now.  You don''t have to interrupt your current
activity, simply, your sync write goes to a dedicated device that''s
guaranteed to be idle in relation to all that other stuff.  Then the sync write
becomes async, and gets coalesced into the pending TXG.

If you don''t have a dedicated log, then the sync write jumps the write
queue, and becomes next in line.  It waits for the present read or write
operation to complete, and then the sync write hits the disk, and flushes the
disk buffer.  This means the sync write suffered a penalty waiting for the main
pool disks to be interruptible.  Without slog, you''re causing delay to
your sync writes, and you''re causing delay before the next read or
write operation can begin...  But that''s it.  Without slog, your
operations are serial, whereas, with slog your sync write can occur in parallel
to your other operations.

There''s no extra fragmentation, with or without slog.  Because in
either case, the sync write hits some dedicated and recyclable disk blocks, and
then it becomes async and coalesced with all the other async writes.  The layout
and/or fragmentation characteristics of the permanent TXG to be written to the
pool is exactly the same either way.

2012-07-30 0:40, opensolarisisdeadlongliveopensolaris
?????:
>> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-
>> bounces at opensolaris.org] On Behalf Of Jim Klimov
>>
>>     For several times now I''ve seen statements on this list
implying
>> that a dedicated ZIL/SLOG device catching sync writes for the log,
>> also allows for more streamlined writes to the pool during normal
>> healthy TXG syncs, than is the case with the default ZIL located
>> within the pool.
>
> It might just be more clear, if it''s stated differently:
>
> At any given time, your pool is in one of four states:  idle, reading,
writing, or idle with writes queued but not currently being written.  Now a sync
write operation takes place.  If you have a dedicated log, it goes directly to
the log, and it doesn''t interfere with any of the other operations that
might be occurring right now.  You don''t have to interrupt your current
activity, simply, your sync write goes to a dedicated device that''s
guaranteed to be idle in relation to all that other stuff.  Then the sync write
becomes async, and gets coalesced into the pending TXG.
>
> If you don''t have a dedicated log, then the sync write jumps the
write queue, and becomes next in line.  It waits for the present read or write
operation to complete, and then the sync write hits the disk, and flushes the
disk buffer.  This means the sync write suffered a penalty waiting for the main
pool disks to be interruptible.  Without slog, you''re causing delay to
your sync writes, and you''re causing delay before the next read or
write operation can begin...  But that''s it.  Without slog, your
operations are serial, whereas, with slog your sync write can occur in parallel
to your other operations.
>
> There''s no extra fragmentation, with or without slog.  Because in
either case, the sync write hits some dedicated and recyclable disk blocks, and
then it becomes async and coalesced with all the other async writes.  The layout
and/or fragmentation characteristics of the permanent TXG to be written to the
pool is exactly the same either way.
Thanks... but doesn''t your description imply that the sync writes
would always be written twice? It should be with dedicated SLOG, but
even with one, I think, small writes hit the SLOG and large ones
go straight to the pool devices (and smaller blocks catch up from
the TXG queue upon TXG flush). However, without a dedicated SLOG,
I thought that the writes into the ZIL happen once on the main
pool devices, and then are referenced from the live block pointer
tree without being rewritten elsewhere (and for the next TXG some
other location may be used for the ZIL). Maybe I am wrong, because
it would also make sense for small writes to hit the disk twice
indeed, and the same pool location(s) being reused for the ZIL.

//Jim

On Jul 29, 2012, at 1:53 PM, Jim Klimov wrote:
> 2012-07-30 0:40, opensolarisisdeadlongliveopensolaris ?????:
>>> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-
>>> bounces at opensolaris.org] On Behalf Of Jim Klimov
>>> 
>>>    For several times now I''ve seen statements on this list
implying
>>> that a dedicated ZIL/SLOG device catching sync writes for the log,
>>> also allows for more streamlined writes to the pool during normal
>>> healthy TXG syncs, than is the case with the default ZIL located
>>> within the pool.
>> 
>> It might just be more clear, if it''s stated differently:
>> 
>> At any given time, your pool is in one of four states:  idle, reading,
writing, or idle with writes queued but not currently being written.  Now a sync
write operation takes place.  If you have a dedicated log, it goes directly to
the log, and it doesn''t interfere with any of the other operations that
might be occurring right now.  You don''t have to interrupt your current
activity, simply, your sync write goes to a dedicated device that''s
guaranteed to be idle in relation to all that other stuff.  Then the sync write
becomes async, and gets coalesced into the pending TXG.
>> 
>> If you don''t have a dedicated log, then the sync write jumps
the write queue, and becomes next in line.  It waits for the present read or
write operation to complete, and then the sync write hits the disk, and flushes
the disk buffer.  This means the sync write suffered a penalty waiting for the
main pool disks to be interruptible.  Without slog, you''re causing
delay to your sync writes, and you''re causing delay before the next
read or write operation can begin...  But that''s it.  Without slog,
your operations are serial, whereas, with slog your sync write can occur in
parallel to your other operations.
>> 
>> There''s no extra fragmentation, with or without slog.  Because
in either case, the sync write hits some dedicated and recyclable disk blocks,
and then it becomes async and coalesced with all the other async writes.  The
layout and/or fragmentation characteristics of the permanent TXG to be written
to the pool is exactly the same either way.
> 
> Thanks... but doesn''t your description imply that the sync writes
> would always be written twice? It should be with dedicated SLOG, but
> even with one, I think, small writes hit the SLOG and large ones
> go straight to the pool devices (and smaller blocks catch up from
> the TXG queue upon TXG flush). However, without a dedicated SLOG,
> I thought that the writes into the ZIL happen once on the main
> pool devices, and then are referenced from the live block pointer
> tree without being rewritten elsewhere (and for the next TXG some
> other location may be used for the ZIL). Maybe I am wrong, because
> it would also make sense for small writes to hit the disk twice
> indeed, and the same pool location(s) being reused for the ZIL.
You are both right and wrong, at the same time. It depends on the data.
Without a slog, writes that are larger than zfs_immediate_write_sz are
written to the permanent place in the pool. Please review (again) my 
slides on the subject.
	http://www.slideshare.net/relling/zfs-tutorial-lisa-2011
slide 78.

For those who prefer to be lecturered, another opportunity will arise in
December 2012 in San Diego at the LISA''12 conference.. I am revamping
much of the material from 2011, to catch up with all of the cool new things
that arrived and are due this year.
 -- richard

--
ZFS Performance and Training
Richard.Elling at RichardElling.com
+1-760-896-4422







-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20120729/c29b38f7/attachment-0001.html>

> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-
> bounces at opensolaris.org] On Behalf Of Jim Klimov
> 
> Thanks... but doesn''t your description imply that the sync writes
> would always be written twice? 
That is correct, regardless of whether you have slog or not.  In the case of
slog, it gets written first to a dedicated device, and then to the pool.  In the
case of no-slog, it gets written to dedicated ZIL recyclable blocks in the main
pool, and then it gets written to the main pool again as part of the next TXG.

All of this is true, except when the sync write is sufficiently large.  When
it''s larger than a configurable threshold (I forget which parameter,
but I could look it up) then it goes directly to the main pool and skips the ZIL
completely.  I don''t know how exactly that is implemented - Maybe it
goes into the next TXG and simply forces the next TXG to flush immediately.

> >  For several times now I''ve seen statements on this list
implying
> > that a dedicated ZIL/SLOG device catching sync writes for the log,
> > also allows for more streamlined writes to the pool during normal
> > healthy TXG syncs, than is the case with the default ZIL located
> > within the pool.
> 
> After reading what some others have posted, I should remind that zfs
> always has a ZIL (unless it is specifically disabled for testing).
> If it does not have a dedicated ZIL, then it uses the disks in the
> main pool to construct the ZIL. Dedicating a device to the ZIL should
> not improve the pool storage layout because the pool already had a
> ZIL.
Also keep in mind that if you have an SLOG (ZIL on a separate device), and then
lose this SLOG (disk crash etc), you will probably lose the pool. So if you
want/need SLOG, you probably want two of them in a mirror?

Vennlige hilsener / Best regards

roy
--
Roy Sigurd Karlsbakk
(+47) 98013356
roy at karlsbakk.net
http://blogg.karlsbakk.net/
GPG Public key: http://karlsbakk.net/roysigurdkarlsbakk.pubkey.txt
--
I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er
et element?rt imperativ for alle pedagoger ? unng? eksessiv anvendelse av
idiomer med xenotyp etymologi. I de fleste tilfeller eksisterer adekvate og
relevante synonymer p? norsk.

On Mon, Jul 30, 2012 at 8:58 AM, Roy Sigurd Karlsbakk <roy at
karlsbakk.net> wrote:
>> >  For several times now I''ve seen statements on this list
implying
>> > that a dedicated ZIL/SLOG device catching sync writes for the log,
>> > also allows for more streamlined writes to the pool during normal
>> > healthy TXG syncs, than is the case with the default ZIL located
>> > within the pool.
>>
>> After reading what some others have posted, I should remind that zfs
>> always has a ZIL (unless it is specifically disabled for testing).
>> If it does not have a dedicated ZIL, then it uses the disks in the
>> main pool to construct the ZIL. Dedicating a device to the ZIL should
>> not improve the pool storage layout because the pool already had a
>> ZIL.
>
> Also keep in mind that if you have an SLOG (ZIL on a separate device), and
then lose this SLOG (disk crash etc), you will probably lose the pool. So if you
want/need SLOG, you probably want two of them in a mirror?
That''s only true on older versions of ZFS.  ZFSv19 (or 20?) includes
the ability to import a pool with a failed/missing log device.  You
lose any data that is in the log and not in the pool, but the pool is
importable.

-- 
Freddie Cash
fjwcash at gmail.com

> > Also keep in mind that if you have an SLOG (ZIL on a separate
> > device), and then lose this SLOG (disk crash etc), you will probably
> > lose the pool. So if you want/need SLOG, you probably want two of
> > them in a mirror?
> 
> That''s only true on older versions of ZFS. ZFSv19 (or 20?)
includes
> the ability to import a pool with a failed/missing log device. You
> lose any data that is in the log and not in the pool, but the pool is
> importable.
Are you sure? I booted this v28 pool a couple of months back, and found it
didn''t recognize its pool, apparently because of a missing SLOG. It
turned out the cache shelf was disconnected, after re-connecting it, things
worked as planned. I didn''t try to force a new import, though, but it
didn''t boot up normally, and told me it couldn''t import its
pool due to lack of SLOG devices.

Vennlige hilsener / Best regards

roy
--
Roy Sigurd Karlsbakk
(+47) 98013356
roy at karlsbakk.net
http://blogg.karlsbakk.net/
GPG Public key: http://karlsbakk.net/roysigurdkarlsbakk.pubkey.txt
--
I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er
et element?rt imperativ for alle pedagoger ? unng? eksessiv anvendelse av
idiomer med xenotyp etymologi. I de fleste tilfeller eksisterer adekvate og
relevante synonymer p? norsk.

On Mon, Jul 30, 2012 at 9:38 AM, Roy Sigurd Karlsbakk <roy at
karlsbakk.net> wrote:
>> > Also keep in mind that if you have an SLOG (ZIL on a separate
>> > device), and then lose this SLOG (disk crash etc), you will
probably
>> > lose the pool. So if you want/need SLOG, you probably want two of
>> > them in a mirror?
>>
>> That''s only true on older versions of ZFS. ZFSv19 (or 20?)
includes
>> the ability to import a pool with a failed/missing log device. You
>> lose any data that is in the log and not in the pool, but the pool is
>> importable.
>
> Are you sure? I booted this v28 pool a couple of months back, and found it
didn''t recognize its pool, apparently because of a missing SLOG. It
turned out the cache shelf was disconnected, after re-connecting it, things
worked as planned. I didn''t try to force a new import, though, but it
didn''t boot up normally, and told me it couldn''t import its
pool due to lack of SLOG devices.
Positive.  :)  I tested it with ZFSv28 on FreeBSD 9-STABLE a month or
two ago.  See the updated man page for zpool, especially the bit about
"import -m".  :)

-- 
Freddie Cash
fjwcash at gmail.com

----- Opprinnelig melding -----
> On Mon, Jul 30, 2012 at 9:38 AM, Roy Sigurd Karlsbakk
> <roy at karlsbakk.net> wrote:
> >> > Also keep in mind that if you have an SLOG (ZIL on a separate
> >> > device), and then lose this SLOG (disk crash etc), you will
> >> > probably
> >> > lose the pool. So if you want/need SLOG, you probably want
two of
> >> > them in a mirror?
> >>
> >> That''s only true on older versions of ZFS. ZFSv19 (or
20?) includes
> >> the ability to import a pool with a failed/missing log device. You
> >> lose any data that is in the log and not in the pool, but the pool
> >> is
> >> importable.
> >
> > Are you sure? I booted this v28 pool a couple of months back, and
> > found it didn''t recognize its pool, apparently because of a
missing
> > SLOG. It turned out the cache shelf was disconnected, after
> > re-connecting it, things worked as planned. I didn''t try to
force a
> > new import, though, but it didn''t boot up normally, and told
me it
> > couldn''t import its pool due to lack of SLOG devices.
> 
> Positive. :) I tested it with ZFSv28 on FreeBSD 9-STABLE a month or
> two ago. See the updated man page for zpool, especially the bit about
> "import -m". :)
On 151a2, man page just says ''use this or that mountpoint''
with import -m, but the fact was zpool refused to import the pool at boot when 2
SLOG devices (mirrored) and 10 L2ARC devices were offline. Should OI/Illumos be
able to boot cleanly without manual action with the SLOG devices gone?

Vennlige hilsener / Best regards

roy
--
Roy Sigurd Karlsbakk
(+47) 98013356
roy at karlsbakk.net
http://blogg.karlsbakk.net/
GPG Public key: http://karlsbakk.net/roysigurdkarlsbakk.pubkey.txt
--
I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er
et element?rt imperativ for alle pedagoger ? unng? eksessiv anvendelse av
idiomer med xenotyp etymologi. I de fleste tilfeller eksisterer adekvate og
relevante synonymer p? norsk.

On Mon, Jul 30, 2012 at 10:20 AM, Roy Sigurd Karlsbakk
<roy at karlsbakk.net> wrote:
> On 151a2, man page just says ''use this or that
mountpoint'' with import -m, but the fact was zpool refused to import
the pool at boot when 2 SLOG devices (mirrored) and 10 L2ARC devices were
offline. Should OI/Illumos be able to boot cleanly without manual action with
the SLOG devices gone?
>From FreeBSD 9-STABLE, which includes ZFSv28:
     zpool import [-o mntopts] [-o property=value] ... [-d dir | -c cachefile]
         [-D] [-f] [-m] [-N] [-R root] [-F [-n]] -a

         Imports all pools found in the search directories. Identical to the
         previous command, except that all pools with a sufficient number of
         devices available are imported. Destroyed pools, pools that were pre-
         viously destroyed with the "zpool destroy" command, will not
be
         imported unless the -D option is specified.

         -o mntopts
                 Comma-separated list of mount options to use when mounting
                 datasets within the pool. See zfs(8) for a description of
                 dataset properties and mount options.

         -o property=value
                 Sets the specified property on the imported pool. See the
                 "Properties" section for more information on the
available
                 pool properties.

         -c cachefile
                 Reads configuration from the given cachefile that was created
                 with the "cachefile" pool property. This cachefile is
used
                 instead of searching for devices.

         -d dir  Searches for devices or files in dir.  The -d option can be
                 specified multiple times. This option is incompatible with
                 the -c option.

         -D      Imports destroyed pools only. The -f option is also required.

         -f      Forces import, even if the pool appears to be potentially
                 active.

         -m      Enables import with missing log devices.


-- 
Freddie Cash
fjwcash at gmail.com

On Mon, 30 Jul 2012, Roy Sigurd Karlsbakk wrote:
>
> Should OI/Illumos be able to boot cleanly without manual action with 
> the SLOG devices gone?
If this is allowed, then data may be unnecessarily lost.

When the drives are not all in one chassis, then it is not uncommon 
for one chassis to not come up immediately, or be slow to come up when 
recovering from a power failure.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

On Jul 30, 2012, at 10:20 AM, Roy Sigurd Karlsbakk
wrote:
> ----- Opprinnelig melding -----
>> On Mon, Jul 30, 2012 at 9:38 AM, Roy Sigurd Karlsbakk
>> <roy at karlsbakk.net> wrote:
>>>>> Also keep in mind that if you have an SLOG (ZIL on a
separate
>>>>> device), and then lose this SLOG (disk crash etc), you will
>>>>> probably
>>>>> lose the pool. So if you want/need SLOG, you probably want
two of
>>>>> them in a mirror?
>>>> 
>>>> That''s only true on older versions of ZFS. ZFSv19 (or
20?) includes
>>>> the ability to import a pool with a failed/missing log device.
You
>>>> lose any data that is in the log and not in the pool, but the
pool
>>>> is
>>>> importable.
>>> 
>>> Are you sure? I booted this v28 pool a couple of months back, and
>>> found it didn''t recognize its pool, apparently because of
a missing
>>> SLOG. It turned out the cache shelf was disconnected, after
>>> re-connecting it, things worked as planned. I didn''t try
to force a
>>> new import, though, but it didn''t boot up normally, and
told me it
>>> couldn''t import its pool due to lack of SLOG devices.
>> 
>> Positive. :) I tested it with ZFSv28 on FreeBSD 9-STABLE a month or
>> two ago. See the updated man page for zpool, especially the bit about
>> "import -m". :)
> 
> On 151a2, man page just says ''use this or that
mountpoint'' with import -m, but the fact was zpool refused to import
the pool at boot when 2 SLOG devices (mirrored) and 10 L2ARC devices were
offline. Should OI/Illumos be able to boot cleanly without manual action with
the SLOG devices gone?
No. Missing slogs is a potential data-loss condition. Importing the pool without
slogs requires acceptance of the data-loss -- human interaction.
 -- richard

--
ZFS Performance and Training
Richard.Elling at RichardElling.com
+1-760-896-4422







-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20120730/0ec57b84/attachment.html>

On Mon, Jul 30, 2012 at 12:44 PM, Richard Elling
<richard.elling at gmail.com>wrote:
> On Jul 30, 2012, at 10:20 AM, Roy Sigurd Karlsbakk wrote:
>
> ----- Opprinnelig melding -----
>
> On Mon, Jul 30, 2012 at 9:38 AM, Roy Sigurd Karlsbakk
>
> <roy at karlsbakk.net> wrote:
>
> Also keep in mind that if you have an SLOG (ZIL on a separate
>
> device), and then lose this SLOG (disk crash etc), you will
>
> probably
>
> lose the pool. So if you want/need SLOG, you probably want two of
>
> them in a mirror?
>
>
> That''s only true on older versions of ZFS. ZFSv19 (or 20?)
includes
>
> the ability to import a pool with a failed/missing log device. You
>
> lose any data that is in the log and not in the pool, but the pool
>
> is
>
> importable.
>
>
> Are you sure? I booted this v28 pool a couple of months back, and
>
> found it didn''t recognize its pool, apparently because of a
missing
>
> SLOG. It turned out the cache shelf was disconnected, after
>
> re-connecting it, things worked as planned. I didn''t try to force
a
>
> new import, though, but it didn''t boot up normally, and told me it
>
> couldn''t import its pool due to lack of SLOG devices.
>
>
> Positive. :) I tested it with ZFSv28 on FreeBSD 9-STABLE a month or
>
> two ago. See the updated man page for zpool, especially the bit about
>
> "import -m". :)
>
>
> On 151a2, man page just says ''use this or that
mountpoint'' with import -m,
> but the fact was zpool refused to import the pool at boot when 2 SLOG
> devices (mirrored) and 10 L2ARC devices were offline. Should OI/Illumos be
> able to boot cleanly without manual action with the SLOG devices gone?
>
>
> No. Missing slogs is a potential data-loss condition. Importing the pool
> without
> slogs requires acceptance of the data-loss -- human interaction.
>  -- richard
>
> --
> ZFS Performance and Training
> Richard.Elling at RichardElling.com
> +1-760-896-4422
>
>
>
I would think a flag to allow you to automatically continue with a
disclaimer might be warranted (default behavior obviously requiring human
input).

--Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20120730/778c1ab8/attachment-0001.html>

On Jul 30, 2012, at 12:25 PM, Tim Cook wrote:
> On Mon, Jul 30, 2012 at 12:44 PM, Richard Elling <richard.elling at
gmail.com> wrote:
> On Jul 30, 2012, at 10:20 AM, Roy Sigurd Karlsbakk wrote:
>> ----- Opprinnelig melding -----
>>> On Mon, Jul 30, 2012 at 9:38 AM, Roy Sigurd Karlsbakk
>>> <roy at karlsbakk.net> wrote:
>>>>>> Also keep in mind that if you have an SLOG (ZIL on a
separate
>>>>>> device), and then lose this SLOG (disk crash etc), you
will
>>>>>> probably
>>>>>> lose the pool. So if you want/need SLOG, you probably
want two of
>>>>>> them in a mirror?
>>>>> 
>>>>> That''s only true on older versions of ZFS. ZFSv19
(or 20?) includes
>>>>> the ability to import a pool with a failed/missing log
device. You
>>>>> lose any data that is in the log and not in the pool, but
the pool
>>>>> is
>>>>> importable.
>>>> 
>>>> Are you sure? I booted this v28 pool a couple of months back,
and
>>>> found it didn''t recognize its pool, apparently because
of a missing
>>>> SLOG. It turned out the cache shelf was disconnected, after
>>>> re-connecting it, things worked as planned. I didn''t
try to force a
>>>> new import, though, but it didn''t boot up normally,
and told me it
>>>> couldn''t import its pool due to lack of SLOG devices.
>>> 
>>> Positive. :) I tested it with ZFSv28 on FreeBSD 9-STABLE a month or
>>> two ago. See the updated man page for zpool, especially the bit
about
>>> "import -m". :)
>> 
>> On 151a2, man page just says ''use this or that
mountpoint'' with import -m, but the fact was zpool refused to import
the pool at boot when 2 SLOG devices (mirrored) and 10 L2ARC devices were
offline. Should OI/Illumos be able to boot cleanly without manual action with
the SLOG devices gone?
> 
> No. Missing slogs is a potential data-loss condition. Importing the pool
without
> slogs requires acceptance of the data-loss -- human interaction.
>  -- richard
> 
> --
> ZFS Performance and Training
> Richard.Elling at RichardElling.com
> +1-760-896-4422
> 
> 
> 
> I would think a flag to allow you to automatically continue with a
disclaimer might be warranted (default behavior obviously requiring human
input).
Disagree, the appropriate action is to boot as far as possible.
The pool will not be imported and will have the normal fault management
alerts generated.

For interactive use, the import will fail, and you can add the -m option.
 -- richard

--
ZFS Performance and Training
Richard.Elling at RichardElling.com
+1-760-896-4422







-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20120730/87698292/attachment.html>

> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-
> bounces at opensolaris.org] On Behalf Of Roy Sigurd Karlsbakk
> 
> > > Also keep in mind that if you have an SLOG (ZIL on a separate
> > > device), and then lose this SLOG (disk crash etc), you will
probably
> > > lose the pool. So if you want/need SLOG, you probably want two of
> > > them in a mirror?
> >
> > That''s only true on older versions of ZFS. ZFSv19 (or 20?)
includes
> > the ability to import a pool with a failed/missing log device. You
> > lose any data that is in the log and not in the pool, but the pool is
> > importable.
> 
> Are you sure? I booted this v28 pool a couple of months back, and found it
> didn''t recognize its pool, apparently because of a missing SLOG.
It turned out
> the cache shelf was disconnected, after re-connecting it, things worked as
> planned. I didn''t try to force a new import, though, but it
didn''t boot up
> normally, and told me it couldn''t import its pool due to lack of
SLOG devices.
You''re not saying contradictory things.  You''re both saying
the same thing.  ;-)

If your slog is unavailable at mount time, then the system has no way to know if
you had previously written anything to slog without flushing to primary storage.
So by default it will refuse to mount.  But as Freddie said, you can force the
import.  If you had any writes queued up in the slog, those writes will be lost,
but the pool is not lost.  Only the most recent few seconds of sync writes.

> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-
> bounces at opensolaris.org] On Behalf Of Tim Cook
> 
> I would think a flag to allow you to automatically continue with a
disclaimer
> might be warranted (default behavior obviously requiring human input).
This already exists.  It''s called disable your ZIL.  (set
sync=disabled).  If you''re willing to lose any writes that were
potentially queued up in your slog, then you really don''t need the
slog.