[ENBD] RAID1 performance

Peter T. Breuer enbd@lists.community.tummy.com
Mon, 27 Jan 2003 19:26:02 +0100 (MET)


"A month of sundays ago Ulrich Hahn wrote:"
> The last few days I did some tests with the new RAID1 code.

OK - thanks. That's 2.4.31, I take it.

> "make test" was flawless, but changing to 2 servers exporting
> 100 GB each revealed some problems.

OK. This is 1000 times bigger than any test I've done!

> At first it seemed to work not at all (in fact it did work, but it was
> awfully slow (>2 hours to build the filesystem)). On the server side I
> got a lot of messages like:
> 
> nbd-shmem 15162<#  53>: maybe_update_seqno_ondisk server writes req seqno
> 8544 (ondisk +2)

One ahead of where it expected. Probably my simple coding error. Not
seen here because I am testing against the same server.

> enbd-server 15159<# 994>: do_srv_write server (0) loses patience waiting
> with req 8659, sector 176520-176527
> 
> these vanished when I changed from "-w 10000" to "-w 0" on the servers
> (this seemed reasonable to me).

OK. I'll look at that.

> Now I was able to make a fs and do some simple tests (dd with 4k
> blocksize).
> With a single nbd device it took 1:40 to dd 2 GB of data, that's
> 20 MB/s. Using the RAID1 setup the same transfer took 8:30, that's
> 4 MB/s. Monitoring traffic on the NIC the single device showed
> oszillations between 15 and 30 MB/s, while the NICs in RAID setup
> oszillated between 0 MB/s and 12 MB/s.
> 
> Any comments on that?

Let me think about it. In principle writes should be twice as slow (the
way things are at the moment) with a single NIC if the NIC is the
limiter, because twice the traffic goes across for the same result.
Being twice as slow as that again is not in itself a disaster. I'd be
pretty happy with that performace ... particularly as I decided to take
the raid code out of the enbd device itself and put it in a separate
driver, and am working on that at the moment.

I'm very interested in that data. I'll ask you some questions later,
when I get out of class.

Petre