linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miquel van Smoorenburg <miquels@cistron.nl>
To: TJ Harrell <systemloc@earthlink.net>
Cc: linux-raid@vger.kernel.org
Subject: Re: Raid1 doesn't balance under high load [patch]
Date: Thu, 10 Jun 2004 16:42:06 +0200	[thread overview]
Message-ID: <20040610144206.GA16625@cistron.nl> (raw)
In-Reply-To: <000c01c44ef0$195820a0$0201a8c0@windows>

According to TJ Harrell:
> I don't know the details of how writing works in the code. I do know that
> consecutive writes must be issued to both disks, though. This means that
> there is a concievable time when one disk is written to and one is not,
> making the array unclean. I'm assuming that this is the reason that the
> array is marked unclean during a write. If you disable this, I would bet
> that it will create a race condition where you may read from a disk before
> it is written to and get old data. This would probably cause data
> corruption, no?

Not when going through the buffer/page cache, which acts as a syncpoint.
If you write a page to disk, it is first put in the pagecache as
"dirty" page. Once the write is complete (meaning both disks have
written it) the page is marked as clean.

If some other process wants to read the same data from disk, it
will go through the buffer/page cache and get the data from the
(dirty or in the mean time clean) page that is there already.
It won't go behind the buffer/pagecache's back to read the data
straight from disk ...

Think about it - all writes to disk-like devices are queued, so if
this didn't happen you'd have that problem all the time.

So the code in there isn't about preventing that at all. It is
really checking for 'is there a rebuild in progress' but it simply
gets that wrong ..

Mike.

  parent reply	other threads:[~2004-06-10 14:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-10 11:30 Raid1 doesn't balance under high load [patch] Miquel van Smoorenburg
     [not found] ` <000c01c44ef0$195820a0$0201a8c0@windows>
2004-06-10 14:42   ` Miquel van Smoorenburg [this message]
2004-06-11  1:26 ` Neil Brown
2004-06-14 11:30   ` Miquel van Smoorenburg
2004-06-14 23:48     ` Neil Brown
  -- strict thread matches above, loose matches on Subject: below --
2004-06-10 13:38 TJ Harrell

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=20040610144206.GA16625@cistron.nl \
    --to=miquels@cistron.nl \
    --cc=linux-raid@vger.kernel.org \
    --cc=systemloc@earthlink.net \
    /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).