From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: write is faster whan seek? Date: Wed, 11 Jun 2008 09:48:26 +0200 Message-ID: <20080611074824.GP20851@kernel.dk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: Dmitri Monakhov Return-path: Received: from brick.kernel.dk ([87.55.233.238]:9337 "EHLO kernel.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752444AbYFKHs1 (ORCPT ); Wed, 11 Jun 2008 03:48:27 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Jun 11 2008, Dmitri Monakhov wrote: > I've found what any non continious sequence violation result in significant > pefrormance drawback. I've two types of requests: > 1)Ideally sequential writes: > for(i=0;i write(fd, chunk, page_size*32); > } > fsync(fd); > > 2) Sequential writes with dgap for each 32'th page > for(i=0;i write(fd, chunk, page_size*31); > lseek(fd, page_size, SEEK_CUR); > } > fsync(fd); > > I've found what second IO pattern is about twice times slower whan the > first one regardless to ioscheduler or HW disk. It is not clear to me > why this happen. Is it linux speciffic or general hardware behaviour > speciffic. I've naively expected what disk hardware cat merge several > 31-paged requests in to continious one by filling holes by some sort > of dummy activity. Performance should be about the same. The first is always going to be a little faster, on some hardware probably quite a bit. Are you using write back caching on the drive? I ran a quick test here, and the second test is about ~5% slower on this drive. -- Jens Axboe