Re: what does xp do when system is copying

j> If I am moving FOO.BAR on the disk to FOO.BAR in another
j> disk area, the CPU does not have to lift each byte, look
j> at it before it writes it.

It does if the disc device is an ATA disc that only supports PIO
operation and not DMA operation. It does if the disc device is an
ATAPI disc that only supports PIO operation and not DMA operation
(which is by far the majority of ATAPI devices).

j> Do you know what this all sounds like? It sounds like the
j> computing biz has reverted back to IBM cards with a format
j> of I1.

No. It's an instance of producing a cheap design initially and then
having to be compatible with it for decades afterwards. Modern ATA
disc units can use DMA, but PIO operation was the original mode of
operation and remains the fallback mode. DMA capability needs to be
sensed before being used, and a working DMA controller (a part of the
PCI-to-ATA bridge chip, and not present on ISA bus systems) also needs
to be present and configured. ("working" is an important word. In
the 1990s, there was a spate of problems with PCI-to-ATA bridge chips
whose DMA didn't work correctly. The CMD 640 was one, but there were
others. See <URL:http://mindprod.com/jgloss/eideflaw.html>.)

The market also militates against hardware that works as you would
like it to. DPT produced a PCI SCSI host bus adapter that operated
much as both you and I would want such a thing to operate. The device
driver set up a control block in memory, and the actual register
interface to the device was as simple as setting a device address
register to the physical address of the control block and saying
"There it is. Go!". The HBA would employ bus-master access to read
the control block directly from system itself, and then perform the
requested operation, using bus-master access to read/write all data
blocks pointed to from the control block. It would raise an interrupt
line when it was done. Adaptec, whose competing HBAs had a rather
more complex interface, bought DPT and discontinued the device.

If it truly is a move, then it is just creating a new directory link to the
file and unlinking the old one.

Tim.

J de Boyne Pollard wrote:
> j> If I am moving FOO.BAR on the disk to FOO.BAR in another
> j> disk area, the CPU does not have to lift each byte, look
> j> at it before it writes it.
>
> It does if the disc device is an ATA disc that only supports PIO
> operation and not DMA operation. It does if the disc device is an
> ATAPI disc that only supports PIO operation and not DMA operation
> (which is by far the majority of ATAPI devices).
>
> j> Do you know what this all sounds like? It sounds like the
> j> computing biz has reverted back to IBM cards with a format
> j> of I1.
>
> No. It's an instance of producing a cheap design initially and then
> having to be compatible with it for decades afterwards. Modern ATA
> disc units can use DMA, but PIO operation was the original mode of
> operation and remains the fallback mode. DMA capability needs to be
> sensed before being used, and a working DMA controller (a part of the
> PCI-to-ATA bridge chip, and not present on ISA bus systems) also needs
> to be present and configured. ("working" is an important word. In
> the 1990s, there was a spate of problems with PCI-to-ATA bridge chips
> whose DMA didn't work correctly. The CMD 640 was one, but there were
> others. See <URL:http://mindprod.com/jgloss/eideflaw.html>.)
>
> The market also militates against hardware that works as you would
> like it to. DPT produced a PCI SCSI host bus adapter that operated
> much as both you and I would want such a thing to operate. The device
> driver set up a control block in memory, and the actual register
> interface to the device was as simple as setting a device address
> register to the physical address of the control block and saying
> "There it is. Go!". The HBA would employ bus-master access to read
> the control block directly from system itself, and then perform the
> requested operation, using bus-master access to read/write all data
> blocks pointed to from the control block. It would raise an interrupt
> line when it was done. Adaptec, whose competing HBAs had a rather
> more complex interface, bought DPT and discontinued the device.
>

On Thu, 20 Sep 2007 11:05:21 -0700
J de Boyne Pollard <> wrote:

> j> If I am moving FOO.BAR on the disk to FOO.BAR in another
> j> disk area, the CPU does not have to lift each byte, look
> j> at it before it writes it.
>
> It does if the disc device is an ATA disc that only supports PIO
> operation and not DMA operation. It does if the disc device is an
> ATAPI disc that only supports PIO operation and not DMA operation
> (which is by far the majority of ATAPI devices).

You are kidding aren't you ? I haven't seen an ATAPI device that
didn't do DMA for *years* - usually they are limited to UDMA33 although I
suspect the 20x speed DVD drives probably do at least UDMA66.

--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/

j> If I am moving FOO.BAR on the disk to FOO.BAR in another
j> disk area, the CPU does not have to lift each byte, look
j> at it before it writes it.

JdeBP> It does if the disc device is an ATA disc that only
JdeBP> supports PIO operation and not DMA operation. It
JdeBP> does if the disc device is an ATAPI disc that only
JdeBP> supports PIO operation and not DMA operation
JdeBP> (which is by far the majority of ATAPI devices).

SOHS> You are kidding aren't you ? I haven't seen an
SOHS> ATAPI device that didn't do DMA for *years* -
SOHS> usually they are limited to UDMA33 although I
SOHS> suspect the 20x speed DVD drives probably
SOHS> do at least UDMA66.

That you haven't seen one for sale recently doesn't mean that there
aren't a lot of them in existence. There are quite a lot of LS-120,
LS-240, ZIP, and other such devices in existence. CD and DVD players
are not the only kinds of ATAPI device. Moreover CD-ROM and DVD-ROM
drives are excluded from the case under consideration here -- which
involves _creating and writing a file_ on the disc, remember.

TL> If it truly is a move, then [...]

No. It's a copy. See the first message in the thread and the subject
field. (-: The person who wrote "moving" wasn't careful about the
distinction.

On Fri, 21 Sep 2007 03:16:31 -0700
J de Boyne Pollard <> wrote:

>> JdeBP> does if the disc device is an ATAPI disc that only
>> JdeBP> supports PIO operation and not DMA operation
>> JdeBP> (which is by far the majority of ATAPI devices).

> SOHS> You are kidding aren't you ? I haven't seen an
> SOHS> ATAPI device that didn't do DMA for *years* -
> SOHS> usually they are limited to UDMA33 although I
> SOHS> suspect the 20x speed DVD drives probably
> SOHS> do at least UDMA66.
>
> That you haven't seen one for sale recently doesn't mean that there
> aren't a lot of them in existence. There are quite a lot of LS-120,
> LS-240, ZIP, and other such devices in existence.

Ah yes OK those things - but they are hardly the majority of ATAPI
devices and I'm not sure they ever were.

> CD and DVD players
> are not the only kinds of ATAPI device. Moreover CD-ROM and DVD-ROM
> drives are excluded from the case under consideration here -- which
> involves _creating and writing a file_ on the disc, remember.

Er DVD+RW and DVD-RAM drives can be used like that and of course
nothing stops a CD-ROM or DVD-ROM being the *source* of such a copy
operation.

--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/

In article < om>,
J de Boyne Pollard <> wrote:
>j> If I am moving FOO.BAR on the disk to FOO.BAR in another

Fix your ****ing prefixing. I thought you were talking to
yourself and not to me. If you hidebound not to prefix with
an attribute line, then at least make the line prefixing unique.

/BAH

In article <fcuf42$tv8$>,
Timothy Lange <> wrote:
>If it truly is a move, then it is just creating a new directory link to the
>file and unlinking the old one.

The term used was copy. That is not a rename (which is what
TOPS-10 called your "move" term). And if the bit transfer
involved to devices, your directory link change won't work.
Think about it before responding.

Please don't toppost.

<pins>

/BAH

In article < .com>,
J de Boyne Pollard <> wrote:
>TL> If it truly is a move, then [...]
>
>No. It's a copy. See the first message in the thread and the subject
>field. (-: The person who wrote "moving" wasn't careful about the
>distinction.

Then you also didn't read what I wrote. The file is getting copied
from one device to another. Whether the original set of bits gets
deleted or not is determined by the specifications of the operating
system.

You must be from that hardware newsgroup; that would explain why
you're a pill.

/BAH