From: Andrew Morton <akpm@osdl.org>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: dan@debian.org, linux-kernel@vger.kernel.org, ext3-users@redhat.com
Subject: Re: ext3 badness in 2.6.0-test2
Date: Thu, 7 Aug 2003 18:16:31 -0700 [thread overview]
Message-ID: <20030807181631.2962dfca.akpm@osdl.org> (raw)
In-Reply-To: <16178.63046.43567.551323@gargle.gargle.HOWL>
Neil Brown <neilb@cse.unsw.edu.au> wrote:
>
> On Tuesday August 5, akpm@osdl.org wrote:
> > Neil Brown <neilb@cse.unsw.edu.au> wrote:
> > > ...
> > > Aug 6 15:22:05 adams kernel: EXT3-fs error (device md1): ext3_add_entry: bad entry in directory #41
> > > 009295: rec_len is smaller than minimal - offset=0, inode=3265411686, rec_len=0, name_len=0
> >
> > It looks like we had a block full of zeroes come back from the device
> > driver. I find it distinctly fishy how this happens so much with
> > ext3-on-md, and so little with ext3-on-just-a-disk.
>
> Well, they're not *all* zero.....
>
> I can reproduce this easily with various configurations of ext3 over
> raid5, and get a similar problem with ext2 over raid5 (corrupt inodes
> rather than directory entries) but ext3 over raid0 is rock-solid.
Good news that it is reproducible.
Have you tried running fsx-linux? It is good at picking up data loss.
> So I guess the finger points generally in the direction of raid5.
> Now I've just got to figure if it is a bug in r5, or some assumption
> that it makes that is no longer valid (I was briefly suspicious of
> PF_READAHEAD which could have made a real mess of raid5, but that
> wouldn't have this symptom)
The PF_READAHEAD things was a huge bug. Make sure that it is fixed before
proceeding. Linus's tree has the fix. This is the relevant patch:
drivers/block/ll_rw_blk.c | 2 +-
fs/buffer.c | 3 +--
include/linux/sched.h | 1 -
mm/readahead.c | 11 +++--------
4 files changed, 5 insertions(+), 12 deletions(-)
diff -puN mm/readahead.c~remove-PF_READAHEAD mm/readahead.c
--- 25/mm/readahead.c~remove-PF_READAHEAD 2003-08-06 19:53:14.000000000 -0700
+++ 25-akpm/mm/readahead.c 2003-08-06 19:53:14.000000000 -0700
@@ -298,15 +298,10 @@ int force_page_cache_readahead(struct ad
int do_page_cache_readahead(struct address_space *mapping, struct file *filp,
unsigned long offset, unsigned long nr_to_read)
{
- int ret = 0;
-
- if (!bdi_read_congested(mapping->backing_dev_info)) {
- current->flags |= PF_READAHEAD;
- ret = __do_page_cache_readahead(mapping, filp,
+ if (!bdi_read_congested(mapping->backing_dev_info))
+ return __do_page_cache_readahead(mapping, filp,
offset, nr_to_read);
- current->flags &= ~PF_READAHEAD;
- }
- return ret;
+ return 0;
}
/*
diff -puN fs/buffer.c~remove-PF_READAHEAD fs/buffer.c
--- 25/fs/buffer.c~remove-PF_READAHEAD 2003-08-06 19:53:14.000000000 -0700
+++ 25-akpm/fs/buffer.c 2003-08-06 19:53:14.000000000 -0700
@@ -506,8 +506,7 @@ static void end_buffer_async_read(struct
set_buffer_uptodate(bh);
} else {
clear_buffer_uptodate(bh);
- if (!(current->flags & PF_READAHEAD))
- buffer_io_error(bh);
+ buffer_io_error(bh);
SetPageError(page);
}
diff -puN drivers/block/ll_rw_blk.c~remove-PF_READAHEAD drivers/block/ll_rw_blk.c
--- 25/drivers/block/ll_rw_blk.c~remove-PF_READAHEAD 2003-08-06 19:53:14.000000000 -0700
+++ 25-akpm/drivers/block/ll_rw_blk.c 2003-08-06 19:53:14.000000000 -0700
@@ -1833,7 +1833,7 @@ static int __make_request(request_queue_
barrier = test_bit(BIO_RW_BARRIER, &bio->bi_rw);
- ra = bio_flagged(bio, BIO_RW_AHEAD) || current->flags & PF_READAHEAD;
+ ra = bio_flagged(bio, BIO_RW_AHEAD);
again:
insert_here = NULL;
diff -puN include/linux/sched.h~remove-PF_READAHEAD include/linux/sched.h
--- 25/include/linux/sched.h~remove-PF_READAHEAD 2003-08-06 19:53:14.000000000 -0700
+++ 25-akpm/include/linux/sched.h 2003-08-06 19:53:14.000000000 -0700
@@ -487,7 +487,6 @@ do { if (atomic_dec_and_test(&(tsk)->usa
#define PF_SWAPOFF 0x00080000 /* I am in swapoff */
#define PF_LESS_THROTTLE 0x00100000 /* Throttle me less: I clean memory */
#define PF_SYNCWRITE 0x00200000 /* I am doing a sync write */
-#define PF_READAHEAD 0x00400000 /* I am doing read-ahead */
#ifdef CONFIG_SMP
extern int set_cpus_allowed(task_t *p, unsigned long new_mask);
_
next prev parent reply other threads:[~2003-08-08 1:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-04 14:22 ext3 badness in 2.6.0-test2 Daniel Jacobowitz
2003-08-04 20:22 ` Andrew Morton
2003-08-06 6:36 ` Neil Brown
2003-08-06 6:57 ` Andrew Morton
2003-08-06 20:18 ` md+ext3 " Frank van de Pol
2003-08-08 1:00 ` ext3 " Neil Brown
2003-08-08 1:16 ` Andrew Morton [this message]
2003-08-09 0:39 ` Neil Brown
2003-08-09 1:05 ` Mike Fedyk
2003-08-10 23:44 ` Neil Brown
-- strict thread matches above, loose matches on Subject: below --
2003-08-06 6:40 rwhron
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=20030807181631.2962dfca.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=dan@debian.org \
--cc=ext3-users@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
/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