Re: [zfs-discuss] ZIL devices and fragmentation

2012-07-31 Thread opensolarisisdeadlongliveopensolaris
 From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
 boun...@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.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZIL devices and fragmentation

2012-07-31 Thread opensolarisisdeadlongliveopensolaris
 From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
 boun...@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.

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZIL devices and fragmentation

2012-07-30 Thread opensolarisisdeadlongliveopensolaris
 From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
 boun...@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.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZIL devices and fragmentation

2012-07-30 Thread Roy Sigurd Karlsbakk
   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
r...@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.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZIL devices and fragmentation

2012-07-30 Thread Freddie Cash
On Mon, Jul 30, 2012 at 8:58 AM, Roy Sigurd Karlsbakk r...@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
fjwc...@gmail.com
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZIL devices and fragmentation

2012-07-30 Thread 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.

Vennlige hilsener / Best regards

roy
--
Roy Sigurd Karlsbakk
(+47) 98013356
r...@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.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZIL devices and fragmentation

2012-07-30 Thread Freddie Cash
On Mon, Jul 30, 2012 at 9:38 AM, Roy Sigurd Karlsbakk r...@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
fjwc...@gmail.com
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZIL devices and fragmentation

2012-07-30 Thread Roy Sigurd Karlsbakk


- Opprinnelig melding -
 On Mon, Jul 30, 2012 at 9:38 AM, Roy Sigurd Karlsbakk
 r...@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
r...@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.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZIL devices and fragmentation

2012-07-30 Thread Freddie Cash
On Mon, Jul 30, 2012 at 10:20 AM, Roy Sigurd Karlsbakk
r...@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
fjwc...@gmail.com
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZIL devices and fragmentation

2012-07-30 Thread Bob Friesenhahn

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
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZIL devices and fragmentation

2012-07-30 Thread Richard Elling
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
 r...@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.ell...@richardelling.com
+1-760-896-4422







___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZIL devices and fragmentation

2012-07-30 Thread Tim Cook
On Mon, Jul 30, 2012 at 12:44 PM, Richard Elling
richard.ell...@gmail.comwrote:

 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

 r...@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.ell...@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
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZIL devices and fragmentation

2012-07-30 Thread Richard Elling
On Jul 30, 2012, at 12:25 PM, Tim Cook wrote:
 On Mon, Jul 30, 2012 at 12:44 PM, Richard Elling richard.ell...@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
 r...@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.ell...@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.ell...@richardelling.com
+1-760-896-4422







___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZIL devices and fragmentation

2012-07-29 Thread Richard Elling
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.ell...@richardelling.com
+1-760-896-4422







___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZIL devices and fragmentation

2012-07-29 Thread Sašo Kiselkov
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
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZIL devices and fragmentation

2012-07-29 Thread Jim Klimov

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
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZIL devices and fragmentation

2012-07-29 Thread Sašo Kiselkov
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
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZIL devices and fragmentation

2012-07-29 Thread Bob Friesenhahn

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
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZIL devices and fragmentation

2012-07-29 Thread opensolarisisdeadlongliveopensolaris
 From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
 boun...@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.


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZIL devices and fragmentation

2012-07-29 Thread Jim Klimov

2012-07-30 0:40, opensolarisisdeadlongliveopensolaris пишет:

From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@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

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZIL devices and fragmentation

2012-07-29 Thread Richard Elling
On Jul 29, 2012, at 1:53 PM, Jim Klimov wrote:

 2012-07-30 0:40, opensolarisisdeadlongliveopensolaris пишет:
 From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
 boun...@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.ell...@richardelling.com
+1-760-896-4422







___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss