Move assignment of i_blkbits field

[lorddoskias]

So this continues my quest in eliminating zfs_inode_update implementation. This change is trivial enough, however when researching it I observed something peculiar. In the linux kernel most filessystem don't set this field directly as its already being set from the generic layer in inode_init_always to sb->s_blocksize_bits. In zfs this field is being set to whatever the current value of the recordsize property is set to. I cannot help it but wonder shouldn't the inode shift bits be set at allocation time to whatever the current s_blocksize_bits is set to, since this is the size of the record that the inode is going to hold?

@behlendorf @dweeezil can you please explain why the inode's shift bits are always seto the minimum allowed shift and not to ilog2(sb->s_blocksize_bits) ?

[behlendorf]

@lorddoskias always setting the block size to SPA_MINBLOCKSHIFT arguably isn't correct but neither is setting it to sb->s_blocksize_bits. The block size for the inode will change up until the maximum record size is reached and the inode contains multiple blocks.

Really the best thing we could do here is update the inode's i_blkbits field when the block size changes along with i_blocks. Then we shouldn't need the sa_object_size() call in zfs_getattr_fast() and could rely on generic_fillattr(). That might even help speed up a getattr although sa_object_size() is already fairly optimized.

[lorddoskias]

@behlendorf Ok, got you. But the current change doesn't really change the semantics, so I think it should be good on its own. I really like to do away with the whole zfs_inode_update conundrum

[behlendorf]

Absolutely. The current patch LGTM.