On Monday December 3, [EMAIL PROTECTED] wrote:
> Hello,
>
> with kernel 2.6.22.10 checking a raid1 or rebuilding ist does not work on one
> of our machines. After a short time the rebuild/check does not make progress
> any more . Processes which then access the filesystems on those raids are
>
Neil Brown schrieb:
>
> This isn't a resync, it is a data check. "Dec 2" is the first Sunday
> of the month. You probably have a crontab entries that does
>echo check > /sys/block/mdX/md/sync_action
>
> early on the first Sunday of the month. I know that Debian does this.
>
> It is good
Hello,
with kernel 2.6.22.10 checking a raid1 or rebuilding ist does not work on one
of our machines. After a short time the rebuild/check does not make progress
any more . Processes which then access the filesystems on those raids are
blocked.
Nothing gets logged. Access to other filesystems
Justin Piszcz wrote:
While we are on the subject of bad blocks, is it possible to do what
3ware raid controllers do without an external card?
They know when a block is bad and they remap it to another part of the
array etc, where as with software raid you never know this is happening
until t
On Mon, 3 Dec 2007, Neil Brown wrote:
On Sunday December 2, [EMAIL PROTECTED] wrote:
Anyway, the problems are back: To test my theory that everything is
alright with the CPU running within its specs, I removed one of the
drives while copying some large files yesterday. Initially, everything
On Mon, 3 Dec 2007, Neil Brown wrote:
On Sunday December 2, [EMAIL PROTECTED] wrote:
Was curious if when running 10 DD's (which are writing to the RAID 5)
fine, no issues, suddenly all go into D-state and let the read/give it
100% priority?
So are you saying that the writes completely stal
On Sunday December 2, [EMAIL PROTECTED] wrote:
>
> Was curious if when running 10 DD's (which are writing to the RAID 5)
> fine, no issues, suddenly all go into D-state and let the read/give it
> 100% priority?
So are you saying that the writes completely stalled while the read
was progressing?
On Sunday December 2, [EMAIL PROTECTED] wrote:
>
> Anyway, the problems are back: To test my theory that everything is
> alright with the CPU running within its specs, I removed one of the
> drives while copying some large files yesterday. Initially, everything
> seemed to work out nicely, and by
root 2206 1 4 Dec02 ?00:10:37 dd if /dev/zero of 1.out
bs 1M
root 2207 1 4 Dec02 ?00:10:38 dd if /dev/zero of 2.out
bs 1M
root 2208 1 4 Dec02 ?00:10:35 dd if /dev/zero of 3.out
bs 1M
root 2209 1 4 Dec02 ?00:10:45 dd if /dev/
On Mon, 3 Dec 2007, Michael Tokarev wrote:
Justin Piszcz said: (by the date of Sun, 2 Dec 2007 04:11:59 -0500 (EST))
The badblocks did not do anything; however, when I built a software raid 5
and the performed a dd:
/usr/bin/time dd if=/dev/zero of=fill_disk bs=1M
I saw this somewhere
> Justin Piszcz said: (by the date of Sun, 2 Dec 2007 04:11:59 -0500 (EST))
>
>> The badblocks did not do anything; however, when I built a software raid 5
>> and the performed a dd:
>>
>> /usr/bin/time dd if=/dev/zero of=fill_disk bs=1M
>>
>> I saw this somewhere along the way:
>>
>> [42332.
On Sun, 2 Dec 2007, Janek Kozicki wrote:
Justin Piszcz said: (by the date of Sun, 2 Dec 2007 04:11:59 -0500 (EST))
The badblocks did not do anything; however, when I built a software raid 5
and the performed a dd:
/usr/bin/time dd if=/dev/zero of=fill_disk bs=1M
I saw this somewhere al
> Justin Piszcz schrieb:
> >
> > Naturally, when it is reset, the device is disconnected and then
> > re-appears, when MD see's this it rebuilds the array.
Least you can do is to add an internal bitmap to your raid, this will
make rebuilds faster :-/
--
Janek Kozicki
Justin Piszcz said: (by the date of Sun, 2 Dec 2007 04:11:59 -0500 (EST))
> The badblocks did not do anything; however, when I built a software raid 5
> and the performed a dd:
>
> /usr/bin/time dd if=/dev/zero of=fill_disk bs=1M
>
> I saw this somewhere along the way:
>
> [42332.936706] a
> -Original Message-
> From: ChristopherD [mailto:[EMAIL PROTECTED]
> Sent: Sunday, December 02, 2007 4:03 AM
> To: linux-raid@vger.kernel.org
> Subject: Abysmal write performance on HW RAID5
>
>
> In the process of upgrading my RAID5 array, I've run into a brick wall
(<
> 4MB/sec avg
Justin Piszcz schrieb:
>
> It rebuilds the array because 'something' is causing device
> resets/timeouts on your USB device:
>
> Dec 1 20:04:49 quassel kernel: usb 4-5.2: reset high speed USB device
> using ehci_hcd and address 4
>
> Naturally, when it is reset, the device is disconnected and t
On Sun, 2 Dec 2007, Oliver Martin wrote:
[Please CC me on replies as I'm not subscribed]
Hello!
I've been experimenting with software RAID a bit lately, using two
external 500GB drives. One is connected via USB, one via Firewire. It is
set up as a RAID5 with LVM on top so that I can easily a
On Sat, 1 Dec 2007, Justin Piszcz wrote:
On Sat, 1 Dec 2007, Janek Kozicki wrote:
Justin Piszcz said: (by the date of Sat, 1 Dec 2007 07:23:41 -0500
(EST))
dd if=/dev/zero of=/dev/sdc
The purpose is with any new disk its good to write to all the blocks and
let the drive to all of
18 matches
Mail list logo
