Dear Sam, Thank you for the quick reply. Sam Douglas ?????:
As I understand it, read and write calls in GlusterFS (and FUSE) are done with supplied offsets (for example read 8192 bytes at position 9024 of the file). This is why seek performance is pretty consistent. The rewrite performance with read-ahead and write-behind drops because writing to the file changes the modification time and invalidates the read-ahead cache. Thus the data that was read was copied needlessly.
So, is there a way to tune it somehow? For now I couldn't think of anything except using very small values for the read-ahead cache. With page-size of 16K and page-count 1 I get Rewrite of about 7000 K/sec but the Sequential Read only about 26000 K/sec which is only a half of the best possible value.
-- WBR, Grigory Shamov
Sam Douglas On Dec 19, 2007 10:56 PM, Grigory Shamov <gas@xxxxxx> wrote:Dear GlusterFS developers, So I did a Bonnie++ benchmark using one of the servers (Dual Opteron, 4GB RAM, SATA disk, CentOS Linux 5) and a client (old P4 2.4GHz box, 512MB RAM, Gigabit Ethernet, CentOS 4.5). I used 8Gb size for the Bonnie++ tests, and tried either forced flush IO or not (-b option; the data below are for the latter case). Some of the Bonnie++ results are like this: =============================================== FileSystem: Sequential Output , K/sec Per-char Block Rewrite =============================================== NFS 14442 30419 7710 Lustre 16012 35228 19018 GlusterFS 16582 15833 8358 GlusterFS, wb 17988 43774 8409 GlusterFS, ra 18414 15863 1804 GlusterFS, ra, wb 22403 41821 355 =============================================== FileSystem: Sequential Input, K/sec Random Per-char Block seeks, #/s =============================================== NFS 20229 49510 178.8 Lustre 17284 47753 53.0 GlusterFS 16791 16815 161.4 GlusterFS, wb 15304 17438 174.1 GlusterFS, ra 19420 54803 143.3 GlusterFS, ra, wb 19900 54427 144.4 ===============================================
