tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Problem identified: WAPL/RAIDframe performance problems

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

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

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 Laight:

Home | Main Index | Thread Index | Old Index