Re: Poor raid 1 performance?

"Antoine Leca" <root@xxxxxxxxxxxxxxxxx> wrote in message news:4396d993$0$16881$636a15ce@xxxxxxxxxxxx
> In news:43946b71$0$61254$892e7fe2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx,
> Folkert Rienstra va escriure:
> > "Antoine Leca" root@xxxxxxxxxxxxxxxxx> wrote in message news:43940b8b$0$6485$636a15ce@xxxxxxxxxxxx
> > > In news:43938fba$0$44448$892e7fe2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, Folkert Rienstra va escriure:
> > > > "Antoine Leca" root@xxxxxxxxxxxxxxxxx> wrote in message news:439089e4$0$21227$626a54ce@xxxxxxxxxxxx
> > >
> > > > > With RAID 1, you cannot make them contiguous or near enough for
> > > > > both writing [every sector] and reading [every two sectors].
> > > >
> > > > So that's obviously not the way to do it.
> > >
> > > Sorry, you are too terse for me. Which "way" are you writing about?
> >
> > You ask me to explain your own writing?
>
> I am sorry it appears I also was too terse...
> No, I believe I understand what I wanted to say ;-) (another thing is the
> meaning of what I actually wrote :-), but it was not the purpose of my
> question above).
>
> I was asking, since you wrote my sentence (describing just an alternative)
> was "obviously not the way to do it", what should be

> "the way to do [RAID 1 data organization on disk]."

And my answer was to leave that alone and to stop thinking about alternate
sector reading and instead go by dividing single sequential transfers into
2 sequential transfers of half size that are executed in parallel.

>
>
> > > > You divide a single request into two and send each half to a
> > > > different drive. With consequtive requests (for a sequential file)
> > > > you sent half the number of total requests to one drive and the
> > > > other half to the other one, resulting in both drives reading
> > > > sequentially.
> [...]
> > You need to get rid of that even/odd numbered sectors fascination and
> > start thinking in disk IO-commands, the way I described in the previous
> > paragraph.
>
> Disk commands are interesting to understand the pros and cons of an inter-
> face implementation (and I agree I missed something here on the first shot;

I'm still not convinced that you got it now.

> I'd thank here all that provided me detailled explanations and commentaries,
> by the way.)
>
>
> However, only considering the interface will drive us into a perfect world
> where the disk provides the datas to the controller and up without any delay;

It does, as far as comparing RAID vs non-RAID, leaving access time out of
the equasion.

> and we all know this perfect world is not yet the one we live into.

As long as an IO is issued before it's start sector passes the head there will
be no delays.
However reading only even or uneven sectors has only a 50% effectiveness
as described in the part that you snipped.

>
> So I was _also_ considering the physical organization of the sectors on the
> media. And my idea is that the write operation on the RAID controller will
> not do anything special (in other words, the RAID controller will issue the
> same I/O command to both "disks" as what it received from the upper level,
> including same sector numbers); while the read operation on the RAID
> controller will be splitted as you explained (thanks.)

Which has nothing to do with a changed on-disk organization.

>
> Now, when you look at a lower level ("disk" within quotes above), my idea
> is that the write operation accesses the media without lost time for a
> sequential run of sectors ;

> this in turn means

No, it doesn't.

> that the read operation (which, as seen by the disk, only is about the even-
> resp. odd-numbered sectors, as passed inside the I/O commandes received).

Repeat: That is very ineffective.
Not only 1 sector per IO (high overhead on command vs data transferred, slow)
but also reading at half the normal data rate.

>
> And my (perhaps faulty) conclusion was that this represented a small penalty
> (with respect to e.g. RAID 0,

No, you said "non-Raid".

> where the traffic of I/O commands while reading sequencially is essentially the same),

Go back and read what I said about that.

> because the read operations have to skip some sectors while accessing the media.

That reminds me of Danyel Goodwin who once maintained that drives could read
slightly faster than they could write because they could skip the heads settling
field between header and data while they were reading.
As if the drive could jump ahead in time, skipping that field.

Sectors pass as slow or as fast as normal, whether you read them or not.
They take their usual time to pass. Read half of them, get half the throughput.

>
>
> Antoine
.

Relevant Pages

  • Re: Poor raid 1 performance?
    ... > start thinking in disk IO-commands, the way I described in the previous ... So I was _also_ considering the physical organization of the sectors on the ... And my idea is that the write operation on the RAID controller will ... same I/O command to both "disks" as what it received from the upper level, ...
    (comp.sys.ibm.pc.hardware.storage)
  • Re: How to store big files contiguously on hd
    ... For better transfer rate when reading. ... The big files will be place once on the hard disk and then they will ... list of bad sectors (I think bad sectors is more accurate than bad ... not give you access to their defect lists, ...
    (comp.unix.admin)
  • getting oddball boundary quirk reading Samsung disk
    ... Brand new disk. ... Reading 1 sector at a time works fine. ... Reading 2 sectors gives i/o error. ... I ran the same incoming inspection test on Seagates, ...
    (freebsd-questions)
  • Re: 2.4: "access beyond end of device" after ext2 mount
    ... dd: reading `/dev/hdg7': Input/output error ... while the ext3 fs is 9992360 sectors. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: Poor raid 1 performance?
    ... and while sequential reading you should wait while ... >> other half to the other one, resulting in both drives reading ... > And since the media have been written sequentially (I assume it, ... You need to get rid of that even/odd numbered sectors fascination and start ...
    (comp.sys.ibm.pc.hardware.storage)