mkfs.xfs: don't increase agblocks past maximum

RH QA discovered this bug:

Steps to Reproduce:
1. Create 4 TB - 1 B partition
dd if=/dev/zero of=x.img bs=1 count=0 seek=4398046511103
2. Create xfs fs with 512 B block size on the partition mkfs.xfs -b size=512 xfs.img

Actual results:
Agsize is computed incorrectly resulting in fs creation fail:
agsize (2147483648b) too big, maximum is 2147483647 blocks

This is due to the "rounding up" at the very end of the calculations; there may be other places to alleviate the problem, but it seems most obvious to simply skip the rounding up if it would create too many blocks in the AG. Worst case, we lose 1 block per AG.

Signed-off-by Eric Sandeen <[email protected]>

---

mkfs/xfs_mkfs.c +3 -1

index 5b3b9a7..856a261 100644
@@ -658,7 +659,9 @@ calc_default_ag_geometry(
 	 * last bit of the filesystem. The same principle applies
 	 * to the AG count, so we don't lose the last AG!
 	 */
-	blocks = (dblocks >> shift) + ((dblocks & xfs_mask32lo(shift)) != 0);
+	blocks = (dblocks >> shift);
+	if (blocks < XFS_AG_MAX_BLOCKS(blocklog))
+		blocks += ((dblocks & xfs_mask32lo(shift)) != 0);
 
 done:
 	*agsize = blocks;

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

Quoted 12 lines · Eric Sandeen

RH QA discovered this bug:

Steps to Reproduce:
1. Create 4 TB - 1 B partition
dd if=/dev/zero of=x.img bs=1 count=0 seek=4398046511103
2. Create xfs fs with 512 B block size on the partition mkfs.xfs -b size=512 xfs.img

Actual results:
Agsize is computed incorrectly resulting in fs creation fail:
agsize (2147483648b) too big, maximum is 2147483647 blocks

Quoted 7 lines

This is due to the "rounding up" at the very end of the calculations; there may be other places to alleviate the problem, but it seems most obvious to simply skip the rounding up if it would create too many blocks in the AG. Worst case, we lose 1 block per AG.

Signed-off-by Eric Sandeen <[email protected]>

---

The fix is the right way about it.

This may seem petty, but I think this would be better:

	blocks = dblocks >> shift
	if (blocks & xfs_mask32lo(shift)) {
		if (blocks < XFS_AG_MAX_BLOCKS(blocklog))
			blocks++;
	}

It emphasizes more why we'd be doing the increment, plus I'd rather see a "real" increment rather than adding a Boolean value.

Either way:

Reviewed-by Alex Elder <[email protected]>

Quoted 13 lines

mkfs/xfs_mkfs.c +3 -1

index 5b3b9a7..856a261 100644
@@ -658,7 +659,9 @@ calc_default_ag_geometry(
 	 * last bit of the filesystem. The same principle applies
 	 * to the AG count, so we don't lose the last AG!
 	 */
-	blocks = (dblocks >> shift) + ((dblocks & xfs_mask32lo(shift)) != 0);
+	blocks = (dblocks >> shift);
+	if (blocks < XFS_AG_MAX_BLOCKS(blocklog))
+		blocks += ((dblocks & xfs_mask32lo(shift)) != 0);
 

Quoted 7 lines

mkfs/xfs_mkfs.c +0 -0

 done:
 	*agsize = blocks;

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

Yes, that's probably better. More code change ... making it more readable.

I'll check it in that way (or, maybe you can, since I can't reach the git repo)?

RH QA discovered this bug:

Steps to Reproduce:
1. Create 4 TB - 1 B partition
dd if=/dev/zero of=x.img bs=1 count=0 seek=4398046511103
2. Create xfs fs with 512 B block size on the partition mkfs.xfs -b size=512 xfs.img