Re: File Fragmentation

On Wednesday 07 December 2005 12:41, Jean-David Beyer stood up and spoke
the following words to the masses in /comp.os.linux.misc...:/

> Aragorn wrote:
>> On Tuesday 06 December 2005 16:39, Jean-David Beyer stood up and
>> spoke the following words to the masses in /comp.os.linux.misc...:/
>>
>>
>>> Peter T. Breuer wrote:
>>>
>>>> Jean-David Beyer <jdbeyer@xxxxxxxxxxx> wrote:
>>>>
>>>>
>>>>> Well some buffering, including read-ahead and write-behind (and
>>>>> therefore, reordering of actual hardware transfers to and from the
>>>>> disk platters) _is_ done in some hardware out there.
>>>>
>>>> Sure - but classical IDE only understands one outstanding request
>>>> at a time, so it's not going to get much elevator reordering out of
>>>> that.
>>>>
>>>> Scsi is better - I think 32 queues requests at a time is quite
>>>> common.
>>>
>>> My SCSI controller is
> chip on motherboard, attached
>>> to a PCI-X bus that is driven by an Intel P64H2 chip (part of the
>>> Intel E7501 chip set); that PCI-X bus runs at 100 MHz, and while
>>> there is one slot for a card, nothing is plugged into it, so it can
>>> run the SCSI controllers at full speed. The dual SCSI controller
>>> data *** claims all kinds of great things, but does not say how
>>> many requests it can queue at a time, though it does say multiple.
>>> Transmits 320 Megabytes per second per channel (simultaneously on
>>> that PCI-X bus). Claims to transmit multiple commands, data contexts
>>> and statuses in a single
>>> connection, and supports Quick Arbitration and Selection (QAS) and
>>> SCSI arbitration fairness. QAS reduces the overhead of control
>>> release on the SCSI bus from one device to another. blah blah blanh.
>>>
>>> I hope it does queue a lot of requests, since I have 4 SCSI hard
>>> drives on one channel of that controller (and my tape drive on the
>>> other. I am thinking of replacing the two IDE drives with SCSI
>>> drives and putting them on the SCSI channel with the tape drive).
>>
>>
>> The default queue depth for your SCSI driver is 32 - per channel, I
>> presume - but the maximum is 253, albeit that this is not advised
>> because of the limitations in the kernel SCSI mid-layer.
>>
> Peter _thinks_ so, and you _presume_ it, but the manufacturer's data
> *** is silent on that point. Where do I find out what it really is?
>
> Is this it?
>
>
http://www.adaptec.fr/worldwide/common/index.html?prodkey=ultra320_index

Possibly, but that depends on your exact adapter card and the driver
used by it. I don't think your adapter card could have 512 queues.

>> Innovative Technologies
>>
>> Adaptec's Ultra320 SCSI implementation features Seamless Streaming,
>> Embedded Mirroring and works seamlessly with Zero-Channel RAID.
>>
>> Adaptec Seamless StreamingTM technology optimizes Ultra320 SCSI
>> performance by ensuring fast, smooth handling of data and SCSI
>> commands. Previous SCSI technology transferred one command at a time;
>> with Adaptec's technology innovations, now up to 512 commands are
>> sent at one time, maximizing PCI-X and Ultra320 SCSI performance.
>
> Does that mean I could send up to 512 commands, possibly at the same
> time?

That's the idea, yes.

> Or does it mean I must send them at the same time or not at all?

No, that would be ridiculous, wouldn't it be? I don't see where you get
this. SCSI disks are _designed_ for multi-threading, unlike IDE disks.

> Or does it mean I could send them at any time, but if there were 512
> unexecuted commands, I could not send anymore until some were done?

No, you are missing the point. The card can execute 512 - in this
example - queues simultaneously. However, the two drivers below - one
of which is the one you need for your adapter - have their limit at a
maximum of 253.

> Where is this limit of 32 set? Is it because there is a queue "in the
> kernel SCSI mid-layer" whose maximum size is 32 or something?

The limit is set in the driver at compile time. If you've ever compiled
your own kernel, you would have come across this option.

The maximum for the /aic7xxx/ (U2/UW/U2W/U160) and /aic79xx/ (U320)
drivers is 253 in the Linux kernel, but a default of 32 is chosen - at
least for the latter driver - because of memory limitations within the
Linux SCSI mid-layer.

Setting higher values could cause problems in systems with many SCSI
disks - e.g. high-end servers - hence the default of 32.

The kernel configurator offers explanations regarding this.

> A quick look at the driver headers (without actually understanding how
> the driver works) leads me to believe it is limited to 256, but I sure
> could be wrong.

253 for the two drivers I've mentioned above.

--
With kind regards,

*Aragorn*
(Registered GNU/Linux user #223157)
.

Loading