bsd: Implement some of the kobj functions

FreeBSD implements the kobj functions through the use of vnode operations,
whereas I simplified things by making use of system calls.
Otherwise, a bunch of code would have to be ported and adapted.
I'm only implementing here those needed by the function spa_config_load.

Reviewed-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
zfs: Re-enable spa_config_load

After the patch 'bsd: Implement kobj function set', spa_config_load can now be
re-enabled. spa_config_load is called during the spa (storage pool allocator)
initialization phase, i.e. spa_init(), and it's intended to populate the SPA
namespace with information stored in the pool configuration files.

Reviewed-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
tests: Make misc-fs-stress work on ZFS on Linux

ZFS on Linux doesn't support the O_DIRECT flag.

Reviewed-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
scripts: Add script for benchmarking ZFS mount time

The script basically stresses the ZFS dataset with misc-fs-stress, and
lately measures ZFS mount time.

Output example:
$ sudo ./scripts/benchs/zfs_mount.py --samples 3
Running ZFS mount time benchmark, total samples: 3
unit of time: millisecond (ms)
id	time	min	max	avg	stdev
--	----	---	---	---	-----
1	103.0	103.0	103.0	103.0	0.0
2	73.5	73.5	103.0	88.2	10.4
3	76.8	73.5	103.0	84.5	9.6

Reviewed-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
zfs: Improve mount time when previous instance has performed I/O

This patch considerably improves ZFS mount time when the previous OSv
instance has performed some I/O.
I tried the same type of benchmark on ZFS on Linux, and the results have
shown that apparently it's not affected by the same problem.

After tracing and investigation, the result showed that the slowness exists
at spa_load_impl procedure, whose purpose is to load an existent storage
pool. Back in time, it was discussed in our mailing list about things being
unfinished in the storage pool, being carried over to the next OSv instance,
and consequently slowing down the next ZFS mount.

The overall problem is quite complex, and requires further investigation to
discover everything about. I'm here coming up with a temporary solution which
consists of syncing all the pools when the last ZFS dataset is being unmounted.

Result:

:: BEFORE ::
$ sudo ./scripts/benchs/zfs_mount.py --samples 10
Running ZFS mount time benchmark, total samples: 10
unit of time: millisecond (ms)
id	time	min	max	avg	stdev
--	----	---	---	---	-----
1	2417.8	2417.8	2417.8	2417.8	0.0
2	1329.3	1329.3	2417.8	1873.6	384.8
3	2949.5	1329.3	2949.5	2232.2	519.8
4	1296.9	1296.9	2949.5	1998.4	570.7
5	3337.5	1296.9	3337.5	2266.2	700.1
6	3399.8	1296.9	3399.8	2455.1	746.4
7	3358.2	1296.9	3399.8	2584.1	750.4
8	2946.7	1296.9	3399.8	2629.5	710.9
9	3002.2	1296.9	3399.8	2670.9	679.2
10	1169.5	1169.5	3399.8	2520.8	773.2

:: AFTER ::
$ sudo ./scripts/benchs/zfs_mount.py --samples 10
Running ZFS mount time benchmark, total samples: 10
unit of time: millisecond (ms)
id	time	min	max	avg	stdev
--	----	---	---	---	-----
1	103.0	103.0	103.0	103.0	0.0
2	73.5	73.5	103.0	88.2	10.4
3	76.8	73.5	103.0	84.5	9.6
4	91.8	73.5	103.0	86.3	8.7
5	120.0	73.5	120.0	93.0	14.4
6	84.3	73.5	120.0	91.6	13.5
7	162.7	73.5	162.7	101.7	26.2
8	103.9	73.5	162.7	102.0	24.5
9	80.0	73.5	162.7	99.6	24.0
10	127.8	73.5	162.7	102.4	24.2

Reviewed-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>