| To: | Kevin Xu <cgxu.gg@xxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH]fix fbno in xfs_dir2_node_addname_int |
| From: | David Chinner <dgc@xxxxxxx> |
| Date: | Tue, 25 Mar 2008 09:16:45 +1100 |
| Cc: | xfscn@xxxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx |
| In-reply-to: | <47E5A982.8010002@xxxxxxxxx> |
| References: | <47E5A982.8010002@xxxxxxxxx> |
| Sender: | xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.4.2.1i |
On Sun, Mar 23, 2008 at 08:51:14AM +0800, Kevin Xu wrote:
> if we didn't find a freespace block for our new entry in the current
> freeindex block,
> return to the first freeindex block and continue to check.
What is the test case that demonstrates this problem?
Looking at the impact of setting fbno = -1 if we don't find a
suitable free space, the next iteration of the loop will do:
1454 if (fbp == NULL) {
1455 /*
1456 * Happens the first time through unless lookup
gave
1457 * us a freespace block to start with.
1458 */
1459 if (++fbno == 0)
1460 fbno = XFS_DIR2_FREE_FIRSTDB(mp);
and
define XFS_DIR2_FREE_FIRSTDB(mp) \
xfs_dir2_byte_to_db(mp, XFS_DIR2_FREE_OFFSET)
Is a fixed offset into the directory. Hence resetting fbno = -1 will
force us to look up the same freespace block on every loop iteration.
That looks like it will livelock as soon as the first free space block
does not have enough space for the desired entry......
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Poor VMWare disk performance on XFS partition, Josef 'Jeff' Sipek |
|---|---|
| Next by Date: | Re: [PATCH]fix the algorithm for addname in xfs_da_node_lookup_int, David Chinner |
| Previous by Thread: | [PATCH]fix fbno in xfs_dir2_node_addname_int, Kevin Xu |
| Next by Thread: | [PATCH]fix the algorithm for addname in xfs_da_node_lookup_int, Kevin Xu |
| Indexes: | [Date] [Thread] [Top] [All Lists] |