From: "Theodore Ts'o" <tytso@mit.edu>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Jun Nie <jun.nie@linaro.org>,
adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ext4: fix underflow in group bitmap calculation
Date: Fri, 23 Dec 2022 00:08:23 -0500 [thread overview]
Message-ID: <Y6U3x3Cs8Mzaakkx@mit.edu> (raw)
In-Reply-To: <Y6SdOzSr5CW5nQl/@magnolia>
On Thu, Dec 22, 2022 at 10:08:59AM -0800, Darrick J. Wong wrote:
>
> Question -- on a 1k-block filesystem, are the first 1024 bytes of the
> device *reserved* by ext4 for whatever bootloader crud goes in there?
> Or is that space undefined in the filesystem specification?
>
> I never did figure that out when I was writing the ondisk specification
> that's in the kernel, but maybe you remember?
That's an interesting (and philosophical) question. The ext2 file
system never had a formal specification, and this part of the file
system format was devised by Remy Card before I had gotten involved
with ext2. (I first got started writing e2fsprogs; which replaced the
previous file system utilities, which were forked from minix's tools,
and which were quite inefficient.)
In favor of it being undefined, the first 1024 bytes are not part of
any block group in an ext2 file system with a 1k block size. (The
first block group is composed of physical blocks 1 through 8192
inclusive when the block size is 1k. Whereas if the blocksize is 4k,
the first block group is composed of physical blocks 0 through 32767.)
In addition, the status of the first 1024 bytes is not controlled by
an ext2 block allocation bitmap.
One could also argue that to the extent that ext2 was derived the ext
file system, which in turn was derived from Minix --- and Minix File
System (which does have a specification, explicitly states that "block
0" is reserved for the Bootloader, with "Block 1" being the location
of the superblock. But Minix only supports a 1k blocksize, and
doesn't have the concept of FFS-style block (cylinder) groups.
So I'd come down on the side which states that the first 1024 bytes
are "undefined" on a 1k block file system.
(One could also aruge that they are "undefined" on a 2k and 4k block
file system, but the first 1024 bytes are part of "block 0", and on 2k
and 4k block file systems, "block 0" is part of a block group.)
> If those first 1024 bytes are defined to be reserved in the ondisk
> format, then you could return a mapping for those bytes with the owner
> code set to EXT4_FMR_OWN_UNKNOWN.
>
> If, however, the space is undefined, then going off this statement in
> the manpage:
>
> "For example, if the low key (fsmap_head.fmh_keys[0]) is set to (8:0,
> 36864, 0, 0, 0), the filesystem will only return records for extents
> starting at or above 36 KiB on disk."
>
> I think the 'at or above' clause means that ext4 should not pass back
> any mapping for the byte range 0-1023 on a 1k-block filesystem.
Sure, sounds good to me.
- Ted
prev parent reply other threads:[~2022-12-23 5:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-22 2:02 [PATCH] ext4: fix underflow in group bitmap calculation Jun Nie
2022-12-22 17:41 ` Theodore Ts'o
2022-12-22 18:08 ` Darrick J. Wong
2022-12-23 5:08 ` Theodore Ts'o [this message]
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=Y6U3x3Cs8Mzaakkx@mit.edu \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=djwong@kernel.org \
--cc=jun.nie@linaro.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@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