From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org
Cc: Parisc List <linux-parisc@vger.kernel.org>
Subject: [BUG] mke2fs produces corrupt filesystem if badblock list contains a block under 251
Date: Mon, 01 Jul 2019 15:44:30 -0700 [thread overview]
Message-ID: <1562021070.2762.36.camel@HansenPartnership.com> (raw)
Background: we actually use the badblocks feature of the ext filesystem
group to do a poorman's boot filesystem for parisc: Our system chunks
up the disk searching for an Initial Program Loader (IPL) signature and
then executes it, so we poke a hole in an ext3 filesystem at creation
time and place the IPL into it. Our IP can read ext3 files and
directories, so it allows us to load the kernel directly from the file.
The problem is that our IPL needs to be aligned at 256k in absolute
terms on the disk, so, in the usual situation of having a 64k partition
label and the boot partition being the first one we usually end up
poking the badblock hole beginning at block 224 (using a 1k block
size).
The problem is that this used to work long ago (where the value of long
seems to be some time before 2011) but no longer does. The problem can
be illustrated simply by doing
---
# dd if=/dev/zero of=bbtest.img bs=1M count=100
# losetup /dev/loop0 bbtest.img
# a=237; while [ $a -le 450 ]; do echo $a >> bblist.txt; a=$[$a+1]; done
# mke2fs -b 1024 -l /home/jejb/bblist.txt /dev/loop0
---
Now if you try to do an e2fsck on the partition you'll get this
---
# e2fsck -f /dev/loop0
e2fsck 1.45.2 (27-May-2019)
Pass 1: Checking inodes, blocks, and sizes
Programming error? block #237 claimed for no reason in process_bad_block.
Programming error? block #238 claimed for no reason in process_bad_block.
Programming error? block #239 claimed for no reason in process_bad_block.
Programming error? block #240 claimed for no reason in process_bad_block.
Programming error? block #241 claimed for no reason in process_bad_block.
Programming error? block #242 claimed for no reason in process_bad_block.
Programming error? block #243 claimed for no reason in process_bad_block.
Programming error? block #244 claimed for no reason in process_bad_block.
Programming error? block #245 claimed for no reason in process_bad_block.
Programming error? block #246 claimed for no reason in process_bad_block.
Programming error? block #247 claimed for no reason in process_bad_block.
Programming error? block #248 claimed for no reason in process_bad_block.
Programming error? block #249 claimed for no reason in process_bad_block.
Programming error? block #250 claimed for no reason in process_bad_block.
Programming error? block #251 claimed for no reason in process_bad_block.
Programming error? block #252 claimed for no reason in process_bad_block.
Programming error? block #253 claimed for no reason in process_bad_block.
Programming error? block #254 claimed for no reason in process_bad_block.
Programming error? block #255 claimed for no reason in process_bad_block.
Programming error? block #256 claimed for no reason in process_bad_block.
Programming error? block #257 claimed for no reason in process_bad_block.
Programming error? block #258 claimed for no reason in process_bad_block.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (7556, counted=7578).
Fix<y>?
---
So mke2fs has created an ab-inito corrupt filesystem. Empirically,
this only seems to happen if there is a block in the bad block list
under 251, but I haven't verified this extensively.
James
next reply other threads:[~2019-07-01 22:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-01 22:44 James Bottomley [this message]
2019-07-02 0:23 ` [BUG] mke2fs produces corrupt filesystem if badblock list contains a block under 251 Theodore Ts'o
2019-07-02 0:53 ` James Bottomley
2019-07-02 17:33 ` Theodore Ts'o
2019-07-02 19:31 ` James Bottomley
2019-07-02 20:39 ` Theodore Ts'o
2019-07-03 0:37 ` James Bottomley
2019-07-05 16:25 ` Question about ext4 testing: need to produce a high depth extent tree to verify mapping code James Bottomley
2019-07-05 17:39 ` Matthew Wilcox
2019-07-05 18:49 ` James Bottomley
2019-07-05 21:40 ` Darrick J. Wong
2019-07-06 4:02 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1562021070.2762.36.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).