NCQ general question

i am thinking of buying a promise card sataII pcix.
they have two types, a card which support NCQ
and another that does not.
What is the bennifit of buying  a card with NCQ tagging ?

i would be thankfull for any answer .
thank you.
raz.
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NCQ general question

Raz Ben-Jehuda(caro) wrote:
> i am thinking of buying a promise card sataII pcix.
> they have two types, a card which support NCQ
> and another that does not.
> What is the bennifit of buying  a card with NCQ tagging ?
>   
How about: http://en.wikipedia.org/wiki/Native_command_queueing
> i would be thankfull for any answer .
> thank you.
> raz.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>   

	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

when --add after a fail?

Hi all,

   i've been using raid1 sisnce quite a loto of time. Sporadiccaly an array
   fails a disk and in many situations I can just pull the device into the
   array with

      mdadm /dev/mdN --add failded_device

   I've never really understood what is the magic that resurrexes it. I
   thought something related to relocation of bad blocks, but I'm  not at
   all aware of what happens "there"...

   Is that a correct trial to do?

   Now I have a device that throuws an error:

srv-ornago:/tmp# mdadm /dev/md2 --add /dev/hdc6 
mdadm: hot add failed for /dev/hdc6: Invalid argument

the kernel complains:
Mar  1 09:34:29 srv-ornago kernel: md: could not bd_claim hdc6.
Mar  1 09:34:29 srv-ornago kernel: md: error, md_import_device() returned -16

   is this enought to say the disk (pretty new, 6 months) is to be changed?
   which checks should I do.

Thanks in advance
sandro
*

Re: raid5 wont restart after disk failure, then corrupts

On Tue, Feb 28, 2006 at 10:08:11PM +0000, Chris Allen wrote:
>
>Yesterday morning we had an io error on /dev/sdd1:
>
>Feb 27 10:08:57 snap25 kernel: SCSI error : <0 0 3 0> return code = 0x10000
>Feb 27 10:08:57 snap25 kernel: end_request: I/O error, dev sdd, sector 50504271
>Feb 27 10:08:57 snap25 kernel: raid5: Disk failure on sdd1, disabling device. Operation continuing on 7 devices
>
>So, I shutdown the system and replaced drive sdd with a new one. 
>When I powered up again, all was not well. The array wouldn't start:
>
>Feb 27 13:36:02 snap25 kernel: md: md0: raid array is not clean -- starting background reconstruction
....
>Feb 27 13:36:02 snap25 kernel: raid5: cannot start dirty degraded array for md0

something happened whan you shut down the system and the superblock on
the drives was not updated

>I tried assembling the array with --force, but this would produce exactly the
>same results as above - the array would refuse to start.
>
>QUESTION: What should I have done here? Each time I have tried this in the past, I
recreate the array with a missing drive in place of sdd.
mount your fs readonly (as ext2 in case it was ext3) and verify that all
data is readable.

>have had no problems restarting the array and adding the new disk. What had gone
>wrong, and why wouldn't the array start?
something happened whan you shut down the system and the superblock on
the drives was not updated

No syncing after crash. Is this a software raid bug?

I have a FC4 installation (upgraded from FC3) using kernel
version 2.6.15-1.1831_FC4. I see some symptoms in the software
raid, which I'm not quite happy about.

After an unclean shutdown caused by a crash or power failure,
it does not resync the md devices. I have tried comparing the
contents of the two mirrors for each of the md devices. And I
found that on the swap device, there were differences.

Isn't this a bug in the software raid? Shouldn't it always
resync after reboot, if there could possibly be any difference
between the contents on the two disks?

I know that as long as only swap is affected, it is not going
to cause data loss. But how can I be sure it is not going to
happen on file systems as well?

Should I report this as a bug in Fedora Core or did I miss
something?

--

-- 
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_=" <at> 2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC] Generic Migration

Hi all,

I hope I won't bore you too much, but I had these ideas on my mind for
a couple of days now, so I just wanted to share them to you.
It is not a long document, so I guess it would take 10mins to read.
Sorry for my sometimes obscure english, ya know, I did the best I could...

I do welcome any comments, critics, suggestions, ... especially
because it's really a first draft here.

I of course would wish to implement what i'm speaking about, one day
or another...

Best regards,

F.-E.B.

Generic reshape model for MD

1. Introduction

The aim of this document is to present a concept of generic online md level
migration, such as raid1 to raid5, raid growth, ...
Regardless to implementation issues, the only migrations that are strictly
impossible are those where data (and replications) will not fit in the disk
at the end of the migration. For example, raid5 to raid1 with the same number
of disks is strictly impossible.
The aim of generic migration is to make each migration possible and easily
implementable (if not straitforward), including the ones that would imply 

Re: NCQ general question

Gentoopower wrote:
> Raz Ben-Jehuda(caro) wrote:
>> i am thinking of buying a promise card sataII pcix.
>> they have two types, a card which support NCQ
>> and another that does not.
>> What is the bennifit of buying  a card with NCQ tagging ?
>>   
> How about: http://en.wikipedia.org/wiki/Native_command_queueing

Yuck.. what a lousy wiki entry.

NCQ vs. TCQ:  NCQ has a much more efficient low-level protocol,
making the host-side (controller, operating-system) quite a bit
simpler than with NCQ.

Both use 32-deep queue depths, and neither of them are worth a
damn on Linux yet.  Except possibly in the libata ahci driver,
or vendor-provided drivers (open source, even) for some chipsets.

In theory, NCQ/TCQ can speed up a very busy fileserver that is
handling mostly tiny I/O requests.  Practically no measurable
benefit for single-user systems.

Cheers
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NCQ general question

On Wed, Mar 01 2006, Mark Lord wrote:
> Gentoopower wrote:
> >Raz Ben-Jehuda(caro) wrote:
> >>i am thinking of buying a promise card sataII pcix.
> >>they have two types, a card which support NCQ
> >>and another that does not.
> >>What is the bennifit of buying  a card with NCQ tagging ?
> >>  
> >How about: http://en.wikipedia.org/wiki/Native_command_queueing
> 
> Yuck.. what a lousy wiki entry.

Yeah, it's pretty bogus.

> NCQ vs. TCQ:  NCQ has a much more efficient low-level protocol,
> making the host-side (controller, operating-system) quite a bit
> simpler than with NCQ.

Or in laymens terms - TCQ sucks and NCQ doesn't 
NCQ has many more advantages than TCQ, apart from both a more efficient
low level protocol and ease of implementation. TCQ basically just allows
the drive to do some reordering, it still serializes everything and
requires too many interrupts.

> Both use 32-deep queue depths, and neither of them are worth a
> damn on Linux yet.  Except possibly in the libata ahci driver,
> or vendor-provided drivers (open source, even) for some chipsets.

Eh strange statement, NCQ works just fine in Linux with the NCQ patch.
On AHCI only of course, as that is the only docu I had available.

Re: No syncing after crash. Is this a software raid bug?

On Wed, Mar 01, 2006 at 01:44:33PM +0100, Kasper Dupont wrote:
>Should I report this as a bug in Fedora Core or did I miss
>something?
>
you forgot to post evidence

L.

--

-- 
Luca Berra -- bluca <at> comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NCQ general question

Mark Lord wrote:
> Gentoopower wrote:
>> Raz Ben-Jehuda(caro) wrote:
>>> i am thinking of buying a promise card sataII pcix.
>>> they have two types, a card which support NCQ
>>> and another that does not.
>>> What is the bennifit of buying  a card with NCQ tagging ?
>>>   
>> How about: http://en.wikipedia.org/wiki/Native_command_queueing
>
> Yuck.. what a lousy wiki entry.
>
> NCQ vs. TCQ:  NCQ has a much more efficient low-level protocol,
> making the host-side (controller, operating-system) quite a bit
> simpler than with NCQ.
>
> Both use 32-deep queue depths, and neither of them are worth a
> damn on Linux yet.  Except possibly in the libata ahci driver,
> or vendor-provided drivers (open source, even) for some chipsets.
>
> In theory, NCQ/TCQ can speed up a very busy fileserver that is
> handling mostly tiny I/O requests.  Practically no measurable
> benefit for single-user systems.
That's a lousy comment

Single-User systems can have lots of I/O requests too.
If I compile something in the backround, listen to music, while copying
files from one drive to the other.
I also have lots of I/O while booting.
I have two seagates in my box a 160GB 7200.7 and 160GB 7200.9(SATAII