Re: Problem identified: WAPL/RAIDframe performance problems

[David Laight <david%l8s.co.uk@localhost>]

On Tue, Dec 04, 2012 at 02:57:52PM +0000, David Holland wrote:
>  > 
>  > What's a kernel panic got to do with it?  If you hand the controller
>  > and thus the drive 4K write, the kernel panicing won't suddenly cause
>  > you to reverse time and have issued 8 512-byte writes instead.
> 
> That depends on additional properties of the pathway from the FS to
> the drive firmware. It might have sent 1 of 2 2048-byte writes before
> the panic, for example. Or it might be a vintage controller incapable
> of handling more than one sector at a time.

The ATA command set supports writes of multiple sectors and multi-sector
writes (probably not using those terms though!).

In the first case, although a single command is written the drive
will (effectively) loop through the sectors writing them 1 by 1.
All drives support this mode.

For multi-sector writes, the data transfer for each group of sectors
is done as a single burst. So if the drive supports 8 sector multi-sector
writes, and you are doing PIO transfers, you take a single 'data'
interrupt and then write all 4k bytes at once (assuming 512 byte sectors).
The drive identify response indicates whether multi-sector writes are
supported, and if so how many sectors can be written at once.
If the data transfer is DMA, it probably makes little difference to the
driver.

For quite a long time the netbsd ata driver mixes them up - and would
only request writes of multiple sectors if the drive supported multi-sector
writes.

Multi-sector writes are probably quite difficult to kill part way through
since there is only one DMA transfer block.

>  > Given how drives actually write data, I would not be so sanguine
>  > that any sector, of whatever size, in-flight when the power fails,
>  > is actually written with the values you expect, or not written
>  > at all.
> 
> Yes, I'm aware of that. It remains a useful approximation, especially
> for already-existing FS code.

Given that (AFAIK) a physical sector is not dissimilar from an hdlc frame,
once the write has started the old data is gone, it the write is actually
interrupted you'll get a (correctable) bad sector.
If you are really unlucky the write will be long - and trash the
following sector (I managed to power off a floppy controller before it
wrecked the rest of a track when I'd reset the writer with write enabled).
If you are really, really unlucky I think it is possible to destroy
adjacent tracks.

        David

-- 
David Laight: david%l8s.co.uk@localhost