linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Phil Turmel <philip@turmel.org>
To: hansbkk@gmail.com
Cc: linux-raid@vger.kernel.org, linux-lvm@redhat.com
Subject: Re: [linux-lvm] Q: LVM over RAID, or plain disks? A:"Yes" = best of both worlds?
Date: Wed, 01 Dec 2010 07:50:29 -0500	[thread overview]
Message-ID: <4CF64495.80700@turmel.org> (raw)
In-Reply-To: <AANLkTin4f=W69mr923KhSYT_qvFnLiz0fpScWo0w1rfu@mail.gmail.com>

On 11/30/2010 11:45 PM, hansbkk@gmail.com wrote:
> On Tue, Nov 30, 2010 at 11:56 PM, Phil Turmel <philip@turmel.org> wrote:
> 
>> (Actually, rsync and tar are both hardlink-aware, at least the versions I use.)
> 
> My backup filesystems contain so many hardlinks (millions, constantly
> growing) that file-level tools choke - this really must be done at the
> block device level - see my previous post for more detail.

Ah -- I did miss that detail.

> It's also now clear to me that rsync is the tool to use for this for
> all the other LVs without such problematic filesystems, as I know the
> tool and trust its error-checking routines.

Indeed.  I push my own critical systems offsite with rsync+ssh.

[snip /]

>> I would use dd.
> 
> OK, that's clear, thanks.
> 
> 
>> You want your dismountable disks to be accessible stand-alone, but I don't see why that would preclude setting them up so each is a unique LVM VG.
> 
> It doesn't preclude it, but it's a layer of complexity during the data
> recovery process I'm trying to avoid.
> 
> The ultimate goal is a plain partition on a plain disk that can be
> directly mounted on a SATA2 host via a normal recovery/LiveCD by a
> user that's never heard of RAID or LVM.

Ah -- not *you*.  And you wouldn't be mixing customers on a disk, I presume?

> To summarize your feedback:
> 
>   - mdraid's sync error-checking routines don't add value over dd to
> ensure accurate cloning of a static partition; its metadata is just
> useless overhead in this case.

Right.

>   - dd is reliable enough

I guess if your filer lacks ECC ram, you could have a bit flip between reading and writing that would be missed.  It's really an end-to-end hardware integrity issue at this level.  But an undetected read error between the platter and RAM will be propagated by every block-level software tool out there, including software raid.  btrfs can do data-checksumming, but that's at the FS level.

> One last question (and I do realize it's now OT for here, so I won't
> be hurt if it's ignored :)
> 
> Does dd already do some sort of "verify after copy"? I will likely
> investigate the available COTS partition cloning tools as well.

Not natively, but it fairly easy to pipe a dd reader through md5sum to a dd writer, then follow up with a dd read + md5sum of the copied partition (taking care to read precisely the same number of sectors).

The various flavors of ddrescue might have something like this..  didn't check.

> Thanks for all your help, not least in helping me to clarify my own goals

You're welcome.

Phil

  reply	other threads:[~2010-12-01 12:50 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AANLkTimTYse7vnqZydc1Z5z60vNuQw3juj7J_W7+bQEm@mail.gmail.com>
2010-11-28 15:31 ` [linux-lvm] Q: LVM over RAID, or plain disks? A:"Yes" = best of both worlds? hansbkk
2010-11-29 16:27   ` Lars Ellenberg
2010-11-29 17:00     ` hansbkk
2010-11-29 18:57   ` Nataraj
2010-11-30  5:20     ` hansbkk
2010-11-30  7:14       ` Nataraj
2010-11-30  7:34         ` hansbkk
2010-11-30 13:13           ` Phil Turmel
2010-11-30 15:39             ` hansbkk
2010-11-30 16:56               ` Phil Turmel
2010-12-01  4:45                 ` hansbkk
2010-12-01 12:50                   ` Phil Turmel [this message]
2010-12-01 19:47                     ` hansbkk
2010-11-30 15:41           ` Andrew Gideon
2010-11-30 15:53             ` hansbkk
2010-11-30 15:54               ` hansbkk
     [not found] ` <2D.98.07087.690A2FC4@cdptpa-omtalb.mail.rr.com>
2010-11-29 11:01   ` [linux-lvm] " hansbkk
2010-11-29 15:29     ` Keld Jørn Simonsen

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=4CF64495.80700@turmel.org \
    --to=philip@turmel.org \
    --cc=hansbkk@gmail.com \
    --cc=linux-lvm@redhat.com \
    --cc=linux-raid@vger.kernel.org \
    /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).