linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rogier Wolff <R.E.Wolff@BitWizard.nl>
To: Ted Ts'o <tytso@mit.edu>
Cc: Rogier Wolff <R.E.Wolff@bitwizard.nl>,
	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: Mon, 10 Jan 2011 09:49:12 +0100	[thread overview]
Message-ID: <20110110084912.GE21505@bitwizard.nl> (raw)
In-Reply-To: <20110109145838.GA3346@thunk.org>

On Sun, Jan 09, 2011 at 09:58:38AM -0500, Ted Ts'o wrote:
> 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);

It is one form of "defense", but not what I call defensive
programming. Defensive programming, is that you make things robust in
the the face of unexpected changes. 

If you do the BUG_ON and do this throughout the code, one day your
grandson will be increasing the superblock size. He'll fix all the
BUG_ON and your other "defensive" measures. But lo and behold. He's
human, and forgot one or two. Especially the run-time detections that
only get called occasionally (like in this case on an error
sitatuation) might take a while before they are noticed.

What use is it to turn a "we've found a serious error in your
filesystem, we strongly recommend you no longer write to it and run
fsck first" into a "system halted"?

What is wrong with just putting the right formula where it belongs?

We need to set the variable "len" to the amount of free space beyond
the superblock in the first block of the filesystem.  So we take the
size of the first block, subtract the size of the superblock and we
subtract the start of the superblock. It's as simple as that.


> 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.

How about


Makefile: 
	ext4.o: ...the objects.... testsbsize.out

	testsbsize.out:	testsbsize
		./testsbsize

(oh and something about useing "hostcc" for testsbsize). 

with testsbsize.c:
	#include <stdio.h>
	#include <...ext4....> 
	int main (int argc, char **argv)
	{
		if (sizeof (struct ext4_super_block) != 1024) {
			fprintf (stderr, "Superblock size is %d, should be 1024.\n", sizeof (struct ext4_super_block));
			exit (1);
		}
		exit (0);
	}

Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ

  parent reply	other threads:[~2011-01-10  8:49 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
2011-01-10  7:45                         ` Andreas Dilger
2011-01-10  8:49                         ` Rogier Wolff [this message]
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=20110110084912.GE21505@bitwizard.nl \
    --to=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 \
    --cc=tytso@mit.edu \
    /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).