From: Mike Fedyk <mfedyk@matchmail.com>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: Joe Thornber <thornber@sistina.com>,
Andrew Morton <akpm@osdl.org>,
Tupshin Harper <tupshin@tupshin.com>,
linux-kernel@vger.kernel.org, Jens Axboe <axboe@suse.de>
Subject: Re: data corruption using raid0+lvm2+jfs with 2.6.0-test3
Date: Sun, 17 Aug 2003 10:50:50 -0700 [thread overview]
Message-ID: <20030817175050.GX1027@matchmail.com> (raw)
In-Reply-To: <16190.51307.990399.306100@gargle.gargle.HOWL>
On Sun, Aug 17, 2003 at 10:12:27AM +1000, Neil Brown wrote:
> On Saturday August 16, mfedyk@matchmail.com wrote:
> > I have a raid5 with "4" 18gb drives, and one of the "drives" is two 9gb
> > drives in a linear md "array".
> >
> > I'm guessing this will hit this bug too?
>
> This should be safe. raid5 only ever submits 1-page (4K) requests
> that are page aligned, and linear arrays will have the boundary
> between drives 4k aligned (actually "chunksize" aligned, and chunksize
> is atleast 4k).
>
So why is this hitting with raid0? Is lvm2 on top of md the problem and md
on lvm2 is ok?
> So raid5 should be safe over everything (unless dm allows striping
> with a chunk size less than pagesize).
>
> Thinks: as an interim solution of other raid levels - if the
> underlying device has a merge_bvec_function which is being ignored, we
> could set max_sectors to PAGE_SIZE/512. This should be safe, though
> possibly not optimal (but "safe" is trumps "optimal" any day).
Assuming that sectors are always 512 bytes (true for any hard drive I've
seen) that will be 512 * 8 = one 4k page.
Any chance sector != 512?
next prev parent reply other threads:[~2003-08-17 17:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-12 20:45 data corruption using raid0+lvm2+jfs with 2.6.0-test3 Tupshin Harper
2003-08-12 21:08 ` Christophe Saout
2003-08-12 21:10 ` Tupshin Harper
2003-08-12 21:28 ` Andrew Morton
2003-08-12 23:05 ` Neil Brown
2003-08-13 7:25 ` Joe Thornber
2003-08-15 21:27 ` Mike Fedyk
2003-08-16 8:00 ` Neil Brown
2003-08-16 14:18 ` Lars Marowsky-Bree
2003-08-16 23:52 ` Mike Fedyk
2003-08-17 0:12 ` Neil Brown
2003-08-17 17:50 ` Mike Fedyk [this message]
2003-08-17 23:14 ` Neil Brown
2003-08-18 0:28 ` Mike Fedyk
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=20030817175050.GX1027@matchmail.com \
--to=mfedyk@matchmail.com \
--cc=akpm@osdl.org \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
--cc=thornber@sistina.com \
--cc=tupshin@tupshin.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.