linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sunil Mushran <sunil.mushran@oracle.com>
To: Filipe David Manana <fdmanana@apache.org>
Cc: linux-ext4@vger.kernel.org
Subject: Re: question about file space preallocation with fallocate
Date: Mon, 27 Dec 2010 11:11:14 -0800	[thread overview]
Message-ID: <4D18E4D2.2040504@oracle.com> (raw)
In-Reply-To: <AANLkTinEnRaOEqZM9inVyVYW=hh68BC05f6d4Z6Cp7JF@mail.gmail.com>

On 12/27/2010 09:57 AM, Filipe David Manana wrote:
> On Mon, Dec 27, 2010 at 5:17 PM, Sunil Mushran<sunil.mushran@oracle.com>  wrote:
>> fallocate() gives users the ability to allocate space instantly. One way
>> to compare would be to time just fallocate() with another program
>> writing zeros for that length.
>>
>> But that's not the aim of the syscall. The aim is to allow the fs to
>> allocate
>> the space in as large chunks as possible to allow for better read
>> performance.
>>
>> If you don't do fallocate() and allow writes to allocate in small chunks,
>> as you are doing, the allocations on disks could be interleaved in face of
>> multiple processes doing the same. Fragmented allocations can only hurt
>> read performance.
>>
> Thanks for the clarification Sunil. But preallocation of blocks
> shouldn't also improve write operations? Since each write operation
> will no longer cause the OS/filesystem to allocate blocks for the
> file, therefore should be faster.
>
> Also, any particular advice for improving write performance when all
> the writes are done in append-only fashion?

Even with meta-data journaling, the allocation overhead is tiny
compared to the 1G data write overhead.

Considering you are using ext4, you should benefit from delayed
allocation. But for that you'll need to have enough memory and
be running a 64-bit kernel. That way you wont be limited by the
speed of the disk.

Other option is submitting writes in larger chunks. Say 1MB rather
than 1KB.

  reply	other threads:[~2010-12-27 19:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-27 14:47 question about file space preallocation with fallocate Filipe David Manana
2010-12-27 17:17 ` Sunil Mushran
2010-12-27 17:57   ` Filipe David Manana
2010-12-27 19:11     ` Sunil Mushran [this message]
2011-01-03 17:07   ` Eric Sandeen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D18E4D2.2040504@oracle.com \
    --to=sunil.mushran@oracle.com \
    --cc=fdmanana@apache.org \
    --cc=linux-ext4@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).