| To: | Brian Foster <bfoster@xxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH 01/18] xfs: refactor xfs_inobt_insert() to eliminate loop and support variable count |
| From: | Dave Chinner <david@xxxxxxxxxxxxx> |
| Date: | Fri, 25 Jul 2014 08:10:38 +1000 |
| Cc: | xfs@xxxxxxxxxxx |
| Delivered-to: | xfs@xxxxxxxxxxx |
| In-reply-to: | <1406211788-63206-2-git-send-email-bfoster@xxxxxxxxxx> |
| References: | <1406211788-63206-1-git-send-email-bfoster@xxxxxxxxxx> <1406211788-63206-2-git-send-email-bfoster@xxxxxxxxxx> |
| User-agent: | Mutt/1.5.21 (2010-09-15) |
On Thu, Jul 24, 2014 at 10:22:51AM -0400, Brian Foster wrote:
> Inodes are always allocated in chunks of 64 and thus the loop in
> xfs_inobt_insert() is unnecessary.
I don't believe this is true. The number of inodes allocated at once
is:
mp->m_ialloc_inos = (int)MAX((__uint16_t)XFS_INODES_PER_CHUNK,
sbp->sb_inopblock);
So when the block size is, say, 64k, the number of 512 byte inodes
allocated at once is 128. i.e. 2 chunks. Hence xfs_inobt_insert()
can be called with a inode could of > 64 and therefore the loop is
still necessary...
And, indeed, we might want to increase the allocation size in future
to do entire stripe units or stripe widths of inodes at once:
http://xfs.org/index.php/Improving_inode_Caching#Contiguous_Inode_Allocation
This also means a loop would be required -somewhere-...
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH] xfsprogs: fix typo in mkfs.xfs, Eric Sandeen |
|---|---|
| Next by Date: | Re: [PATCH 05/18] xfs: create macros/helpers for dealing with sparse inode chunks, Dave Chinner |
| Previous by Thread: | [PATCH 01/18] xfs: refactor xfs_inobt_insert() to eliminate loop and support variable count, Brian Foster |
| Next by Thread: | Re: [PATCH 01/18] xfs: refactor xfs_inobt_insert() to eliminate loop and support variable count, Brian Foster |
| Indexes: | [Date] [Thread] [Top] [All Lists] |