xfs: more swap extent fixes for dynamic fork offsets
authorDave Chinner <dchinner@redhat.com>
Tue, 20 Apr 2010 07:00:37 +0000 (17:00 +1000)
committerAlex Elder <aelder@sgi.com>
Mon, 26 Apr 2010 17:38:51 +0000 (12:38 -0500)
commitdd77ef924c835c9813c3f4dc7e9c72e9cd88d238
treebf914944fceab37ca446ded983a00e422c318f5b
parentb91ce4d14a21fc04d165be30319541e0f9204f15
xfs: more swap extent fixes for dynamic fork offsets

A new xfsqa test (226) with a prototype xfs_fsr change to try to
handle dynamic fork offsets better triggers an assertion failure
where the inode data fork is in btree format, yet there is room in
the inode for it to be in extent format. The two inodes look like:

before: ino 0x101 (target), num_extents 11, Max in-fork extents 6, broot size 40, fork offset 96
before: ino 0x115 (temp),  num_extents 5, Max in-fork extents 3, broot size 40, fork offset 56
after: ino 0x101 (target), num_extents 5, Max in-fork extents 6, broot size 40, fork offset 96
after: ino 0x115 (temp), num_extents 11, Max in-fork extents 3, broot size 40, fork offset 56

Basically the target inode ends up with 5 extents in btree format,
but it had space for 6 extents in extent format, so ends up
incorrect. Notably here the broot size is the same, and that is
where the kernel code is going wrong - the btree root will fit, so
it lets the swap go ahead.

The check should not allow the swap to take place if the number of
extents while in btree format is less than the number of extents
that can fit in the inode in extent format. Adding that check will
prevent this swap and corruption from occurring.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
fs/xfs/xfs_dfrag.c