Re: Very poor performances with the bcache-for-upstream branch

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

 



Hi Matthew,

this is a very good question to start with. I am in fact very
surprised by two things:

1. The results I have on a cached filesystem are not that far away
from those I am getting from a not-cached FS;
2. The results I am getting as write performance seems very far from
those that are exposed for a similar benchmark
on bcache front page (accounting for tens of thousand IOPS).

I understand that my benchmark is done on a cached partition set up as
a LVM, and on a file laid out on a XFS formatted VG. This must have a
cost, but this huge ?
I also understand that the SSD on my laptop may have poorer
performances than the one used by Kent for his benchmark, yet the
difference is huge (18.5K >> 454). Hence my eyebrows rising...

Cheers,
Leslie.

On Wed, May 1, 2013 at 5:36 PM, matthew patton <pattonme@xxxxxxxxx> wrote:
>> I am obtaining the following figures, on a cached fs:
>> seq-read: iops=12188
>> rand-read: iops=7392
>> seq-write: iops=430
>> rand-write: iops=454
>
> Just what numbers were you expecting to see? A decent 7200RPM drive can only muster 70 IOPs on a good day. The lies the SSD vendors print in their literature and on the side of the box are almost always done with a blocksize of 512 bytes. So if you're doing 4K operations, divide by 8 at least.
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM Kernel]     [Linux Filesystem Development]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux