linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Robert L. Harris" <Robert.L.Harris@rdlg.net>
To: Brian Schwarz <Brian.Schwarz@veritas.com>
Cc: 'Greg Rasberry' <rgreg-r@pacbell.net>,
	'Linux raid mailing list' <linux-raid@vger.kernel.org>
Subject: Re: Software RAID level 1 issue
Date: Fri, 30 May 2003 14:40:41 -0400	[thread overview]
Message-ID: <20030530184041.GP20195@rdlg.net> (raw)
In-Reply-To: <C587FF391BCAD411B8120008C7864670057DA5B8@mtvxch07.veritas.com>

[-- Attachment #1: Type: text/plain, Size: 3850 bytes --]



Not quite the same.  The Linux kernel has built in RAID as well as LVM.
If he's doing RAID1 as it seems then the LVM isn't needed as that's a
completely separate monster.  I'm thinking it's likely a bad drive that
didn't like the restart.

On a RedHat9 system He's likely using an EXT3 filesystem which by
default has a journal attached which is pretty much the same thing as
the DRL.  The IO cost of the journal on EXT3 is extremely negligable.
At work I have 8 servers with four 600Gig (yes gig) filesystems each.
While building one out I did some different tests using ext2 (no
journal) and ext3, raid0+1 and raid5.  A raid5 system with the journal
is an extremely small impact on a 600 Gig system and even a 1.8TB system
(we had time to play with disk configurations).

In this case the raid is syncing it's mirrors, not fscking the filesystem
so the journal/DRL wouldn't do any good at all.  If one of the disks in
the mirror is having media or other hardware errors it could be trying
and failing thought the kernel has been extremely reliable for me to
just puke on a bad disk and mark the array degraded.

http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Software-RAID-HOWTO.html

Robert


Thus spake Brian Schwarz (Brian.Schwarz@veritas.com):

> Greg,
> 
> Can't help you with the LVM specifics, but I would suggest investigating
> functionality called Dirty Region Logging (DRL). I know we have a feature in
> the VERITAS Volume Manager that tracks changes at a block level so the
> resync can happen much more quickly. Think of it as similar to a transaction
> log or Redo log in Oracle. Not sure if LVM has the same type of
> functionality. Won't help you this time, but will save you next time. One
> trade-off is that it costs you some I/Os to write and clear the log, would
> recommend putting the log on a RAID 10 volume. More info on VERITAS Volume
> Manager at www.veritas.com/linux.
> 
> Regards,
> 
> -Brian
> 
> 
> -----Original Message-----
> From: Greg Rasberry [mailto:rgreg-r@pacbell.net]
> Sent: Friday, May 30, 2003 10:54 AM
> To: 'Linux raid mailing list'
> Subject: Software RAID level 1 issue
> 
> 
> I have a RedHat 9.0 server that went down. On re-start the server has 
> started to come up just fine. It started re-syncing, the first of the raid 
> partitions, the first one went buy fast, then the second took a day and the 
> last drive (md2) has been working on the re-sync for four days (it is 
> fairly large 70 Gig).  We are unable to use the server and cannot pull the 
> data off of it because the drives have not mounted, etc.
> 
> I was wondering if anyone knows if this is normal, and/or how I can get 
> around this problem. I understand that the re-sync is supposed to happen in 
> the background?
> 
> I have only been using Linux for about a year and could really use some 
> help with this, the system has been down for a week.
> Thanks in advance for your help.
> 
> R,
> Greg
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

:wq!
---------------------------------------------------------------------------
Robert L. Harris                     | GPG Key ID: E344DA3B
                                         @ x-hkp://pgp.mit.edu 
DISCLAIMER:
      These are MY OPINIONS ALONE.  I speak for no-one else.

Diagnosis: witzelsucht  	

IPv6 = robert@ipv6.rdlg.net	http://ipv6.rdlg.net
IPv4 = robert@mail.rdlg.net	http://www.rdlg.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2003-05-30 18:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-30 18:28 Software RAID level 1 issue Brian Schwarz
2003-05-30 18:40 ` Robert L. Harris [this message]
2003-05-31 17:44 ` Stef Telford
2003-05-30 20:01   ` Paul Clements
2003-05-30 20:12     ` 3tcdgwg3
2003-05-30 20:31       ` Paul Clements
2003-06-02 18:10         ` 3tcdgwg3
2003-06-02 18:16           ` Paul Clements
2003-11-07  7:29         ` Software RAID level performance 3tcdgwg3
2003-05-31 19:39     ` Software RAID level 1 issue Stef Telford
2003-05-30 21:44       ` Robert L. Harris
2003-05-30 22:04         ` Paul Clements
2003-05-30 23:32           ` Robert L. Harris
2003-05-31 20:21   ` Gregory Leblanc
  -- strict thread matches above, loose matches on Subject: below --
2003-05-30 17:53 Greg Rasberry
2003-05-30 17:53 Adriana Rasberry

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=20030530184041.GP20195@rdlg.net \
    --to=robert.l.harris@rdlg.net \
    --cc=Brian.Schwarz@veritas.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=rgreg-r@pacbell.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).