Bug #21089
closedbluestore: mkfs fsck fails when size has 0x1000 bit set during early rcs
0%
Description
revert f6f1ae3724d593d3709d982c973ec18a25a47b6e
vstart with bluestore block size = 10737422336
stop osd
reapply f6f1ae3724d593d3709d982c973ec18a25a47b6e and build ceph-objectstore-tool
fsck
2017-08-23 22:18:32.594486 7fc8e2afbe80 1 bluestore(/home/sage/src/ceph3/build/dev/osd0) fsck checking freelist vs allocated 2017-08-23 22:18:32.662059 7fc8e2afbe80 -1 bluestore(/home/sage/src/ceph3/build/dev/osd0) fsck error: leaked some space (65536 bytes) 2017-08-23 22:18:32.662156 7fc8e2afbe80 -1 bluestore(/home/sage/src/ceph3/build/dev/osd0) fsck error: 0x2000~4 is leaked
The problem is that the (now fixed) bug resulting in the bitmap freelist create() method marking
size & ~(4096) as used (because it thought the device was smaller by 4k).
Updated by Sage Weil over 6 years ago
- Subject changed from bluestore: mkfs fsck fails when size is not min-alloc-size aligned to bluestore: mkfs fsck fails when size has 0x1000 bit set during early rcs
- Description updated (diff)
Updated by Sage Weil over 6 years ago
More specifically, there are two cases. In both cases, the size is off by one block.
1. freelistmanager's block count does not change, and we need to fix the single trailing bit for the size change
2. freelistmanager's block count does change (new row!), and we need allocate all bits after the new eof
These are tested with these two cases (10gb + 4k and 10g + 4k + 8k) by running v12.1.0 vstart:
bin/init-ceph stop ; MON=1 OSD=1 MDS=0 ../src/vstart.sh -n -x -l --bluestore -d -o 'bluestore block size = 10737430528' -o 'bluestore min alloc size = 65536' ; bin/init-ceph stop osd bin/init-ceph stop ; MON=1 OSD=1 MDS=0 ../src/vstart.sh -n -x -l --bluestore -d -o 'bluestore block size = 10737422336' -o 'bluestore min alloc size = 65536' ; bin/init-ceph stop osd
and the fix is verified by running (master) ceph-objecstore-tool like so:
make ceph-objectstore-tool && rm -f c && CEPH_ARGS="--log-file c --debug-bluestore 30" bin/ceph-objectstore-tool --op fsck --data-path ~/src/ceph4/build/dev/osd0 grep -A4 -B3 'fsck warn' c
and confirming that the first run reports the error and fixes it, and the second run reports no warning at all.