I saw something really similar while moving some very large (300MB to
4GB) files.
I was really surprised to see actual disk I/O (as measured by dstat)
be really horrible.
--
Jon
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
M
Peter Grandi wrote:
[ ... on RAID1, ... RAID6 error recovery ... ]
tn> The use case for the proposed 'repair' would be occasional,
tn> low-frequency corruption, for which many sources can be
tn> imagined:
tn> Any piece of hardware has a certain failure rate, which may
tn> depend on things like
On 1 Dec 2007, Jan Engelhardt uttered the following:
>
> On Dec 1 2007 06:19, Justin Piszcz wrote:
>
>> RAID1, 0.90.03 superblocks (in order to be compatible with LILO, if
>> you use 1.x superblocks with LILO you can't boot)
>
> Says who? (Don't use LILO ;-)
Well, your kernels must be on a 0.90-s
Hello,
On Tuesday 23 October 2007 22:16, Dan Williams wrote:
> The problem with moving this test to async_tx_find_channel() is that it
> imposes extra overhead in the fast path. It would be best if we could
> keep all these decisions in the slow path, or at least hide it from
> architectures th
Dragos wrote:
> Thank you for your very fast answers.
>
> First I tried 'fsck -n' on the existing array. The answer was that If I
> wanted to check a XFS partition I should use 'xfs_check'. That seems to
> say that my array was partitioned with xfs, not reiserfs. Am I correct?
>
> Then I tried th
[EMAIL PROTECTED] (Peter Grandi) writes:
> ms> I just want to give another suggestion. It may or may not be
> ms> possible to repair inconsistent arrays but in either way some
> ms> code there MUST at least warn the administrator that
> ms> something (may) went wrong.
>
> tn> Agreed.
>
> That soun
