0.7-release: Improved dnode allocation and dmu_hold_impl()

[dinatale2]

Porting #6564 to zfs-0.7-release.

Refactor dmu_object_alloc_dnsize() and dnode_hold_impl() to simplify the
code, fix errors introduced by commit dbeb879 (PR #6117) interacting
badly with large dnodes, and improve performance.

• When allocating a new dnode in dmu_object_alloc_dnsize(), update the
  percpu object ID for the core's metadnode chunk immediately. This
  eliminates most lock contention when taking the hold and creating the
  dnode.

• Correct detection of the chunk boundary to work properly with large
  dnodes.

• Separate the dmu_hold_impl() code for the FREE case from the code for
  the ALLOCATED case to make it easier to read.

• Fully populate the dnode handle array immediately after reading a
  block of the metadnode from disk. Subsequently the dnode handle array
  provides enough information to determine which dnode slots are in use
  and which are free.

• Add several kstats to allow the behavior of the code to be examined.

• Verify dnode packing in large_dnode_008_pos.ksh. Since the test is
  purely creates, it should leave very few holes in the metadnode.

• Add test large_dnode_009_pos.ksh, which performs concurrent creates
  and deletes, to complement existing test which does only creates.

With the above fixes, there is very little contention in a test of about
200,000 racing dnode allocations produced by tests 'large_dnode_008_pos'
and 'large_dnode_009_pos'.

name type data
dnode_hold_dbuf_hold 4 0
dnode_hold_dbuf_read 4 0
dnode_hold_alloc_hits 4 3804690
dnode_hold_alloc_misses 4 216
dnode_hold_alloc_interior 4 3
dnode_hold_alloc_lock_retry 4 0
dnode_hold_alloc_lock_misses 4 0
dnode_hold_alloc_type_none 4 0
dnode_hold_free_hits 4 203105
dnode_hold_free_misses 4 4
dnode_hold_free_lock_misses 4 0
dnode_hold_free_lock_retry 4 0
dnode_hold_free_overflow 4 0
dnode_hold_free_refcount 4 57
dnode_hold_free_txg 4 0
dnode_allocate 4 203154
dnode_reallocate 4 0
dnode_buf_evict 4 23918
dnode_alloc_next_chunk 4 4887
dnode_alloc_race 4 0
dnode_alloc_next_block 4 18

The performance is slightly improved for concurrent creates with
16+ threads, and unchanged for low thread counts.

Signed-off-by: Brian Behlendorf behlendorf1@llnl.gov
Signed-off-by: Olaf Faaland faaland1@llnl.gov

[sdm900]

Morning. I'm going to ask the obvious question... does this mean that every sub-point release is going to have potentially un-necessary changes?

We have only just gotten over a corrupt file system due to changes in dnode allocation introduced between release candidates... and here it is being rewritten again.

[behlendorf]

@sdm900 we absolutely want to keep unnecessary changes to a minimum and I'm not happy this was needed either. This branch in intended to get only critical bug fixes, patches to support newly released kernels, etc. Unfortunately, this is required to completely resolve the original issue.

The problem you're referring to regrettably wasn't detected until after 0.7.0 was tagged. An initial minimal fix for this, 45d1abc, was then applied to the 0.7.1 release. Extensive subsequent testing with 100's of concurrent processes revealed it was only a 99.9% fix and there was still an unlikely case which could result in the original problem. This PR resolves that remaining race but it did require some refactoring.

[sdm900]

Thanks for the clarification.