On Thursday December 13, [EMAIL PROTECTED] wrote:
What you could do is set the number of devices in the array to 3 so
they it always appears to be degraded, then rotate your backup drives
through the array. The number of dirty bits in the bitmap will
steadily grow and so resyncs will take
So the obvious follow up question is: for this scenario does it make sense to
only resync the difference between the two bitmaps? E.g. Drive A will have
a current bitmap, B will have a stale bitmap. Presumably one could get away
with just resyncing the difference.
Or is this too much of special
On Dec 14, 2007 11:13 AM, Jeff Breidenbach [EMAIL PROTECTED] wrote:
So the obvious follow up question is: for this scenario does it make sense to
only resync the difference between the two bitmaps?
Never mind, I see why this won't work.
-
To unsubscribe from this list: send the line unsubscribe
Brett Maton wrote:
Hi,
Question for you guys.
A brief history:
RHEL 4 AS
I have a partition with way to many small files on (Usually around a couple of million) that needs to be backed up, standard
methods mean that a restore is impossibly slow due to the sheer volume of files.
On Thursday December 13, [EMAIL PROTECTED] wrote:
How do I create the internal bitmap? man mdadm didn't shed any
light and my brief excursion into google wasn't much more helpful.
mdadm --grow --bitmap=internal /dev/mdX
The version I have installed is mdadm-1.12.0-5.i386 from RedHat
What you could do is set the number of devices in the array to 3 so
they it always appears to be degraded, then rotate your backup drives
through the array. The number of dirty bits in the bitmap will
steadily grow and so resyncs will take longer. Once it crosses some
threshold you set the
Hi,
Question for you guys.
A brief history:
RHEL 4 AS
I have a partition with way to many small files on (Usually around a couple
of million) that needs to be backed up, standard
methods mean that a restore is impossibly slow due to the sheer volume of
files.
Brett Maton wrote:
Hi,
Question for you guys.
A brief history:
RHEL 4 AS
I have a partition with way to many small files on (Usually around a couple of million) that needs to be backed up, standard
methods mean that a restore is impossibly slow due to the sheer volume of files.
On Wednesday December 12, [EMAIL PROTECTED] wrote:
Hi,
Question for you guys.
A brief history:
RHEL 4 AS
I have a partition with way to many small files on (Usually around a couple
of million) that needs to be backed up, standard
methods mean that a restore is
Proposed solution is to use software raid mirror. Before backup starts,
break the soft mirror unmount and backup partition
I use this method for backup once a week.
One challenge is drives aren't great at steaming data quickly (for the resync)
while also doing a lot of random access. Having a
Proposed solution is to use software raid mirror. Before backup starts,
break the soft mirror unmount and backup partition
I use this method for backup once a week.
One challenge is drives aren't great at steaming data quickly (for the resync)
while also doing a lot of random access.
11 matches
Mail list logo
