From: Ted Ts'o <tytso@mit.edu>
To: Rogier Wolff <R.E.Wolff@bitwizard.nl>
Cc: Amir Goldstein <amir73il@gmail.com>,
Ric Wheeler <rwheeler@redhat.com>,
Con Kolivas <kernel@kolivas.org>,
adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org
Subject: Re: Regular ext4 error warning with HD in USB dock
Date: Sun, 9 Jan 2011 09:58:38 -0500 [thread overview]
Message-ID: <20110109145838.GA3346@thunk.org> (raw)
In-Reply-To: <20110109081249.GA32496@bitwizard.nl>
On Sun, Jan 09, 2011 at 09:12:49AM +0100, Rogier Wolff wrote:
> > No. The superblock nor its offset will never change. It's like the
> > syscall ABI, only worse. If we changed it would break *everybody*.
> > Fortunately there is a huge amount of space left over in the 1024 byte
> > superblock.
>
> It's called defensive programming. It prevents bugs before they
> happen. By your reasoning you could've written 2048 or 0x800 there.
Defensive programming would be something like
BUG_ON(sizeof(struct ext4_super_block) != 1024);
(unfortunately #error sizeof(struct ext4_super_block) != 1024 won't
work since #error is handled by the preprocessor, and I don't think we
can trigger a compile-time warning for a structure size issue).
We could add that, if people like. I do have regression tests (i.e.,
boot a system with ext4) which would die if anything like that
changed, though.
And yes, I have similar regression tests in e2fsprogs that would
trigger if the superblock size were to ever change.
- Ted
P.S. The only way I can think of to do it at compile time would be to
build a test .o file with -g, and then use a program like pahole that
pulls the information out of the DWARF information. Might actually be
a good thing to do that, since it could also be useful for automating
searches for unoptimize structures. Unfortunately, many developers
don't have the DWARF utilities installed, so that would add a
dependency on the kernel build.
next prev parent reply other threads:[~2011-01-09 14:59 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-27 22:53 Regular ext4 error warning with HD in USB dock Con Kolivas
2010-12-28 2:53 ` Ted Ts'o
2010-12-28 8:19 ` Rogier Wolff
2010-12-28 9:09 ` Con Kolivas
2010-12-28 10:30 ` Amir Goldstein
2011-01-01 17:20 ` Ric Wheeler
2011-01-02 19:23 ` Amir Goldstein
2011-01-07 5:26 ` Ted Ts'o
2011-01-07 19:41 ` Amir Goldstein
2011-01-07 21:07 ` Amir Goldstein
2011-01-07 22:12 ` Amir Goldstein
2011-01-08 20:28 ` Amir Goldstein
2011-01-08 8:05 ` Rogier Wolff
2011-01-08 20:06 ` Amir Goldstein
2011-01-08 22:00 ` Ted Ts'o
2011-01-09 8:12 ` Rogier Wolff
2011-01-09 14:58 ` Ted Ts'o [this message]
2011-01-10 7:45 ` Andreas Dilger
2011-01-10 8:49 ` Rogier Wolff
2011-01-07 5:28 ` Ted Ts'o
2011-01-07 19:43 ` Amir Goldstein
2011-01-07 20:39 ` Amir Goldstein
2010-12-28 14:15 ` Ted Ts'o
2010-12-28 10:41 ` torn5
[not found] ` <4D19BEF1.9010708-9AbUPqfR1/2XDw4h08c5KA@public.gmane.org>
2010-12-28 14:32 ` Ted Ts'o
2010-12-28 15:02 ` Ben Pfaff
2010-12-28 15:20 ` torn5
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=20110109145838.GA3346@thunk.org \
--to=tytso@mit.edu \
--cc=R.E.Wolff@bitwizard.nl \
--cc=adilger.kernel@dilger.ca \
--cc=amir73il@gmail.com \
--cc=kernel@kolivas.org \
--cc=linux-ext4@vger.kernel.org \
--cc=rwheeler@redhat.com \
/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).