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
next prev parent reply other threads:[~2010-12-01 12:50 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-28 15:30 Q: LVM over RAID, or plain disks? A:"Yes" = best of both worlds? hansbkk
2010-11-28 15:31 ` [linux-lvm] " 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 7:34 ` hansbkk
2010-11-30 13:13 ` Phil Turmel
2010-11-30 13:13 ` Phil Turmel
2010-11-30 15:39 ` hansbkk
2010-11-30 15:39 ` hansbkk
2010-11-30 16:56 ` Phil Turmel
2010-11-30 16:56 ` Phil Turmel
2010-12-01 4:45 ` hansbkk
2010-12-01 4:45 ` hansbkk
2010-12-01 12:50 ` Phil Turmel [this message]
2010-12-01 19:47 ` hansbkk
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
2010-11-28 18:34 ` Leslie Rhorer
2010-11-29 11:01 ` [linux-lvm] " hansbkk
2010-11-29 11:01 ` hansbkk
2010-11-29 15:29 ` [linux-lvm] " Keld Jørn Simonsen
2010-11-29 15:29 ` Keld Jørn Simonsen
2010-11-29 16:00 ` hansbkk
2010-11-30 0:42 ` Neil Brown
2010-11-30 5:35 ` hansbkk
2010-11-30 6:47 ` Neil Brown
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 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.