Chris Eddington wrote:
Hi,
Hi
While on vacation I had one SATA port/cable fail, and then four hours
later a second one fail. After fixing/moving the SATA ports, I can
reboot and all drives seem to be OK now, but when assembled it won't
recognize the filesystem.
That's unusual - if the
BERTRAND Joël wrote:
Chuck Ebbert wrote:
On 11/05/2007 03:36 AM, BERTRAND Joël wrote:
Neil Brown wrote:
On Sunday November 4, [EMAIL PROTECTED] wrote:
# ps auxww | grep D
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME
COMMAND
root 273 0.0 0.0 0 0 ?
On Wed, 2007-11-07 at 10:15 +0100, Goswin von Brederlow wrote:
I wonder if there shouldn't be a way to turn this off (or if there
already is one).
Or more generaly an option to say what is near. Specifically I would
like to teach the raid1 layer that I have 2 external raid boxes with a
16k
On Thu, 8 Nov 2007, BERTRAND Joël wrote:
BERTRAND Joël wrote:
Chuck Ebbert wrote:
On 11/05/2007 03:36 AM, BERTRAND Joël wrote:
Neil Brown wrote:
On Sunday November 4, [EMAIL PROTECTED] wrote:
# ps auxww | grep D
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME
COMMAND
Rik van Riel wrote:
On Thu, 08 Nov 2007 17:28:37 +0100
Goswin von Brederlow [EMAIL PROTECTED] wrote:
Maybe you need more parameter:
Generally a bad idea, unless you can come up with sane defaults (which
do not need tuning 99% of the time) or you can derive these parameters
Goswin von Brederlow wrote:
Konstantin Sharlaimov [EMAIL PROTECTED] writes:
On Wed, 2007-11-07 at 10:15 +0100, Goswin von Brederlow wrote:
I wonder if there shouldn't be a way to turn this off (or if there
already is one).
Or more generaly an option to say what is near. Specifically
Jeff Lessem wrote:
Dan Williams wrote:
The following patch, also attached, cleans up cases where the code
looks
at sh-ops.pending when it should be looking at the consistent
stack-based snapshot of the operations flags.
I tried this patch (against a stock 2.6.23), and it did not work for
On Thu, 08 Nov 2007 17:28:37 +0100
Goswin von Brederlow [EMAIL PROTECTED] wrote:
Maybe you need more parameter:
Generally a bad idea, unless you can come up with sane defaults (which
do not need tuning 99% of the time) or you can derive these parameters
automatically from the RAID configuration
From: Dan Williams [EMAIL PROTECTED]
debug output from Joël's system
handling stripe 7629696, state=0x14 cnt=1, pd_idx=2 ops=0:0:0
check 5: state 0x6 toread read write
f800ffcffcc0 written
check 4: state 0x6 toread read
Hi,
I have created a new raid6:
md0 : active raid6 sdb1[0] sdl1[5] sdj1[4] sdh1[3] sdf1[2] sdd1[1]
6834868224 blocks level 6, 512k chunk, algorithm 2 [6/6] [UU]
[] resync = 21.5% (368216964/1708717056)
finish=448.5min speed=49808K/sec
bitmap: 204/204
Richard Scobie said: (by the date of Thu, 08 Nov 2007 08:13:19 +1300)
What kernel and RAID level is this?
If it's RAID 1, I seem to recall there was a relatively recently fixed
bug for this.
debian etch, stock install
Linux 2.6.18-5-k7 #1 SMP i686 GNU/Linux
The problem was with was
Rik van Riel [EMAIL PROTECTED] writes:
On Thu, 08 Nov 2007 17:28:37 +0100
Goswin von Brederlow [EMAIL PROTECTED] wrote:
Maybe you need more parameter:
Generally a bad idea, unless you can come up with sane defaults (which
do not need tuning 99% of the time) or you can derive these
Jeff Lessem ([EMAIL PROTECTED]) wrote on 6 November 2007 22:00:
Dan Williams wrote:
The following patch, also attached, cleans up cases where the code looks
at sh-ops.pending when it should be looking at the consistent
stack-based snapshot of the operations flags.
I tried this patch
Janek Kozicki wrote:
Richard Scobie said: (by the date of Thu, 08 Nov 2007 08:13:19 +1300)
What kernel and RAID level is this?
If it's RAID 1, I seem to recall there was a relatively recently fixed
bug for this.
debian etch, stock install
Linux 2.6.18-5-k7 #1 SMP i686 GNU/Linux
The
14 matches
Mail list logo
