[developer] Re: [openzfs/openzfs] 9102 zfs should be able to initialize storage devices (#586)

2018-03-09 Thread Daniel Carosone 
Why not just dd a file to a scratch dataset (with no compression, copies=3,
a suitable quota to prevent filling, and whatever other properties you
think might be relevant).

The use case is legitimate, but the need for more code to address it seems
dubious.

On Sat., 10 Mar. 2018, 13:11 George Wilson, 
wrote:

> Reviewed by: John Wren Kennedy john.kenn...@delphix.com
> Reviewed by: Matthew Ahrens mahr...@delphix.com
> Reviewed by: Pavel Zakharov pavel.zakha...@delphix.com
> Reviewed by: Prakash Surya prakash.su...@delphix.com
> PROBLEM
>
> The first access to a block incurs a performance penalty on some platforms
> (e.g. AWS's EBS, VMware VMDKs). Therefore we recommend that volumes are
> "thick
> provisioned", where supported by the platform (VMware). This can create a
> large
> delay in getting a new virtual machines up and running (or adding storage
> to
> an existing Engine). If the thick provision step is omitted, write
> performance
> will be suboptimal until all blocks on the LUN have been written.
> SOLUTION
>
> This feature introduces a way to 'initialize' the disks at install or in
> the
> background to make sure we don't incur this first read penalty.
>
> When an entire LUN is added to ZFS, we make all space available
> immediately,
> and allow ZFS to find unallocated space and zero it out. This works with
> concurrent writes to arbitrary offsets, ensuring that we don't zero out
> something that has been (or is in the middle of being) written. This scheme
> can also be applied to existing pools (affecting only free regions on the
> vdev). Detailed design:
> - new subcommand:zpool initialize [-cs] [ ...]
> - start, suspend, or cancel initialization
> - Creates new open-context thread for each vdev
> - Thread iterates through all metaslabs in this vdev
> - Each metaslab:
> - select a metaslab
> - load the metaslab
> - mark the metaslab as being zeroed
> - walk all free ranges within that metaslab and translate them
> to ranges on the leaf vdev
> - issue a "zeroing" I/O on the leaf vdev that corresponds to a
> free range on the metaslab we're working on
> - continue until all free ranges for this metaslab have been
> "zeroed"
> - reset/unmark the metaslab being zeroed
> - if more metaslabs exist, then repeat above tasks.
> - if no more metaslabs, then we're done.
>
> - progress for the initialization is stored on-disk in the vdev’s leaf
>   zap object. The following information is stored:
> - the last offset that has been initialized
> - the state of the initialization process (i.e. active,
>   suspended, or canceled)
> - the start time for the initialization
>
> - progress is reported via the zpool status command and shows
>   information for each of the videos that are initializing
>
> --
> You can view, comment on, or merge this pull request online at:
>
>   https://github.com/openzfs/openzfs/pull/586
> Commit Summary
>
>- 9102 zfs should be able to initialize storage devices
>
> File Changes
>
>- *M* usr/src/cmd/truss/codes.c
> (4)
>- *M* usr/src/cmd/zpool/zpool_main.c
> (156)
>- *M* usr/src/cmd/ztest/ztest.c
> (98)
>- *M* usr/src/lib/libzfs/common/libzfs.h
> (5)
>- *M* usr/src/lib/libzfs/common/libzfs_pool.c
> (94)
>- *M* usr/src/lib/libzfs/common/libzfs_util.c
> (9)
>- *M* usr/src/lib/libzfs/common/mapfile-vers
> (1)
>- *M* usr/src/lib/libzfs_core/common/libzfs_core.c
> (37)
>- *M* usr/src/lib/libzfs_core/common/libzfs_core.h
> (4)
>- *M* usr/src/lib/libzfs_core/common/mapfile-vers
> (6)
>- *M* usr/src/lib/libzpool/common/llib-lzpool
> (3)
>- *M* usr/src/man/man1m/zpool.1m
> (31)
>- *M* usr/src/pkg/manifests/system-test-zfstest.mf
> (39)
>- *M* usr/src/test/zfs-tests/include/commands.cfg
> (1)
>- *M* usr/src/test/zfs-tests/runfiles/delphix.run
> (13)
>- *A*
>usr/src/test/zfs-tests/tests/functional/cli_root/zpool_initialize/Makefile
>

[developer] [openzfs/openzfs] 9102 zfs should be able to initialize storage devices (#586)

2018-03-09 Thread George Wilson 
Reviewed by: John Wren Kennedy 
Reviewed by: Matthew Ahrens 
Reviewed by: Pavel Zakharov 
Reviewed by: Prakash Surya 

PROBLEM
The first access to a block incurs a performance penalty on some platforms
(e.g. AWS's EBS, VMware VMDKs). Therefore we recommend that volumes are "thick
provisioned", where supported by the platform (VMware). This can create a large
delay in getting a new virtual machines up and running (or adding storage to
an existing Engine). If the thick provision step is omitted, write  performance
will be suboptimal until all blocks on the LUN have been written.

SOLUTION
This feature introduces a way to 'initialize' the disks at install or in the
background to make sure we don't incur this first read penalty.

When an entire LUN is added to ZFS, we make all space available immediately,
and allow ZFS to find unallocated space and zero it out. This works with
concurrent writes to arbitrary offsets, ensuring that we don't zero out
something that has been (or is in the middle of being) written. This scheme
can also be applied to existing pools (affecting only free regions on the
vdev). Detailed design:
- new subcommand:zpool initialize [-cs]  [ ...]
- start, suspend, or cancel initialization
- Creates new open-context thread for each vdev
- Thread iterates through all metaslabs in this vdev
- Each metaslab:
- select a metaslab
- load the metaslab
- mark the metaslab as being zeroed
- walk all free ranges within that metaslab and translate them
  to ranges on the leaf vdev
- issue a "zeroing" I/O on the leaf vdev that corresponds to a
  free range on the metaslab we're working on
- continue until all free ranges for this metaslab have been
  "zeroed"
- reset/unmark the metaslab being zeroed
- if more metaslabs exist, then repeat above tasks.
- if no more metaslabs, then we're done.

- progress for the initialization is stored on-disk in the vdev’s leaf
  zap object. The following information is stored:
- the last offset that has been initialized
- the state of the initialization process (i.e. active,
  suspended, or canceled)
- the start time for the initialization

- progress is reported via the zpool status command and shows
  information for each of the videos that are initializing
You can view, comment on, or merge this pull request online at:

  https://github.com/openzfs/openzfs/pull/586

-- Commit Summary --

  * 9102 zfs should be able to initialize storage devices

-- File Changes --

M usr/src/cmd/truss/codes.c (4)
M usr/src/cmd/zpool/zpool_main.c (156)
M usr/src/cmd/ztest/ztest.c (98)
M usr/src/lib/libzfs/common/libzfs.h (5)
M usr/src/lib/libzfs/common/libzfs_pool.c (94)
M usr/src/lib/libzfs/common/libzfs_util.c (9)
M usr/src/lib/libzfs/common/mapfile-vers (1)
M usr/src/lib/libzfs_core/common/libzfs_core.c (37)
M usr/src/lib/libzfs_core/common/libzfs_core.h (4)
M usr/src/lib/libzfs_core/common/mapfile-vers (6)
M usr/src/lib/libzpool/common/llib-lzpool (3)
M usr/src/man/man1m/zpool.1m (31)
M usr/src/pkg/manifests/system-test-zfstest.mf (39)
M usr/src/test/zfs-tests/include/commands.cfg (1)
M usr/src/test/zfs-tests/runfiles/delphix.run (13)
A 
usr/src/test/zfs-tests/tests/functional/cli_root/zpool_initialize/Makefile (21)
A 
usr/src/test/zfs-tests/tests/functional/cli_root/zpool_initialize/cleanup.ksh 
(31)
A 
usr/src/test/zfs-tests/tests/functional/cli_root/zpool_initialize/zpool_initialize.kshlib
 (43)
A 
usr/src/test/zfs-tests/tests/functional/cli_root/zpool_initialize/zpool_initialize_attach_detach_add_remove.ksh
 (68)
A 
usr/src/test/zfs-tests/tests/functional/cli_root/zpool_initialize/zpool_initialize_import_export.ksh
 (78)
A 
usr/src/test/zfs-tests/tests/functional/cli_root/zpool_initialize/zpool_initialize_offline_export_import_online.ksh
 (66)
A 
usr/src/test/zfs-tests/tests/functional/cli_root/zpool_initialize/zpool_initialize_online_offline.ksh
 (74)
A 
usr/src/test/zfs-tests/tests/functional/cli_root/zpool_initialize/zpool_initialize_split.ksh
 (64)
A 
usr/src/test/zfs-tests/tests/functional/cli_root/zpool_initialize/zpool_initialize_start_and_cancel_neg.ksh
 (60)
A 
usr/src/test/zfs-tests/tests/functional/cli_root/zpool_initialize/zpool_initialize_start_and_cancel_pos.ksh
 (52)
A 
usr/src/test/zfs-tests/tests/functional/cli_root/zpool_initialize/zpool_initialize_suspend_resume.ksh
 (63)
A 
usr/src/test/zfs-tests/tests/functional/cli_root/zpool_initialize/zpool_initialize_unsupported_vdevs.ksh
 (74)
A

[developer] Re: [openzfs/openzfs] 9194 mechanism to override ashift at pool creation time (#570)

2018-03-09 Thread Richard Elling 
richardelling commented on this pull request.



> @@ -1431,6 +1433,7 @@ vdev_open(vdev_t *vd)
vd->vdev_asize = asize;
vd->vdev_max_asize = max_asize;
vd->vdev_ashift = MAX(ashift, vd->vdev_ashift);
+   vd->vdev_ashift = MAX(zfs_ashift_override, vd->vdev_ashift);

A better name is `zfs_ashift_min` which is a fine approach.

For the name `zfs_ashift_override` the expected code is something like:
`vd->vdev_ashift = zfs_ashift_override > 0 ? zfs_ashift_override : 
vd->vdev_ashift;`
which is also a fine approach.

Basically, I'd like to see it become less ambiguous and more consistent with 
other tunables.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/570#discussion_r173607794
--
openzfs: openzfs-developer
Permalink: 
https://openzfs.topicbox.com/groups/developer/discussions/Te17b61abfaa32615-Mb4537cdc078097099d823227
Delivery options: https://openzfs.topicbox.com/groups

[developer] Re: [openzfs/openzfs] 9256 zfs send space estimation off by > 10% on some datasets (#585)

2018-03-09 Thread Matthew Ahrens 
ahrens commented on this pull request.



> @@ -66,6 +66,11 @@ int zfs_send_set_freerecords_bit = B_TRUE;
 static char *dmu_recv_tag = "dmu_recv_tag";
 const char *recv_clone_name = "%recv";
 
+/*
+ * Use this to override the recordsize calculation for fast zfs send estimates.
+ */
+uint64_t zfs_override_estimate_recordsize = 8192;

we should set this to 0 by default in illumos.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/585#pullrequestreview-102832571
--
openzfs: openzfs-developer
Permalink: 
https://openzfs.topicbox.com/groups/developer/discussions/Taed4dee301375635-M4a8c8efc94262d22aa344822
Delivery options: https://openzfs.topicbox.com/groups

[developer] [openzfs/openzfs] 9256 zfs send space estimation off by > 10% on some datasets (#585)

2018-03-09 Thread brad-lewis 
Reviewed by: Matt Ahrens 
Reviewed by: John Kennedy 

Here is an instance where we see a big discrepancy.

estimate is : 431217656 bytes
actual size is : 492215048 bytes

Without the -e flag, the discrepancy is much higher.

Upstream bug: DLPX-45514
You can view, comment on, or merge this pull request online at:

  https://github.com/openzfs/openzfs/pull/585

-- Commit Summary --

  * 9256 zfs send space estimation off by > 10% on some datasets

-- File Changes --

M 
usr/src/test/zfs-tests/tests/functional/cli_root/zfs_send/zfs_send_006_pos.ksh 
(2)
M usr/src/uts/common/fs/zfs/dmu_send.c (11)

-- Patch Links --

https://github.com/openzfs/openzfs/pull/585.patch
https://github.com/openzfs/openzfs/pull/585.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/585

--
openzfs: openzfs-developer
Permalink: 
https://openzfs.topicbox.com/groups/developer/discussions/Taed4dee301375635-M3f2707020a5e5d273adbeef5
Delivery options: https://openzfs.topicbox.com/groups

[developer] [openzfs/openzfs] 9255 obsolete_counts feature should be documented in zpool-features.5… (#584)

2018-03-09 Thread brad-lewis 
… manpage

Reviewed by: Sebastien Roy 
Reviewed by: Serapheim Dimitropoulos 
Reviewed by: Steve Gonczi 

This is part of device removal that should be documented.

Upstream bug: DLPX-47652
You can view, comment on, or merge this pull request online at:

  https://github.com/openzfs/openzfs/pull/584

-- Commit Summary --

  * 9255 obsolete_counts feature should be documented in zpool-features.5 
manpage

-- File Changes --

M usr/src/man/man5/zpool-features.5 (23)

-- Patch Links --

https://github.com/openzfs/openzfs/pull/584.patch
https://github.com/openzfs/openzfs/pull/584.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/584

--
openzfs: openzfs-developer
Permalink: 
https://openzfs.topicbox.com/groups/developer/discussions/T25f219f797dd6b4e-Mb401c0169cb4605ca8a9102f
Delivery options: https://openzfs.topicbox.com/groups