All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Andrew Morton <andrewm@uow.edu.au>
Cc: Andreas Dilger <adilger@turbolinux.com>,
	"Stephen C. Tweedie" <sct@redhat.com>,
	Manas Garg <mls@chakpak.net>,
	linux-kernel@vger.kernel.org
Subject: Re: O_TRUNC problem on a full filesystem
Date: Fri, 25 May 2001 10:42:03 +0100	[thread overview]
Message-ID: <20010525104203.F7952@redhat.com> (raw)
In-Reply-To: <3B0CF068.A6ADA562@uow.edu.au> <200105241724.f4OHOAhQ014259@webber.adilger.int> <3B0DA651.8151AE93@uow.edu.au>
In-Reply-To: <3B0DA651.8151AE93@uow.edu.au>; from andrewm@uow.edu.au on Fri, May 25, 2001 at 10:24:49AM +1000

Hi,

On Fri, May 25, 2001 at 10:24:49AM +1000, Andrew Morton wrote:

> For example, when we miss the goal block we search forward
> up to 63 blocks for a *single* free block, and use that.
> Perhaps we shouldn't?

The reasoning here is that it's much cheaper to go to a single block
which is very nearby than to be forced to use that single block later
on as part of some distant file once the disk becomes fuller.  It's a
sort of opportunistic fragmentation: if we can sneak in a disk
allocation that uses the awkward block without requiring a seek (and
in all likelihood coming out of the track buffer), then we reduce the
overall impact on performance of that isolated free block.

> And perhaps the search for eight contiguous free blocks
> is no longer appropriate to current disks.  32 may be better?

I've thought about that but today we're usually allocating in 4k
chunks rather than 1k so it's normally a 32k preallocation which we
get, anyway.

Cheers,
 Stephen

      reply	other threads:[~2001-05-25  9:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-23  6:13 O_TRUNC problem on a full filesystem Manas Garg
2001-05-23  9:16 ` OT: " Helge Hafting
2001-05-23  9:55 ` Andrew Morton
2001-05-24 11:16   ` Stephen C. Tweedie
2001-05-24 11:28     ` Andrew Morton
2001-05-24 17:24       ` Andreas Dilger
2001-05-24 18:15         ` Stephen C. Tweedie
2001-05-24 20:26           ` Andreas Dilger
2001-05-25  0:24         ` Andrew Morton
2001-05-25  9:42           ` Stephen C. Tweedie [this message]

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=20010525104203.F7952@redhat.com \
    --to=sct@redhat.com \
    --cc=adilger@turbolinux.com \
    --cc=andrewm@uow.edu.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mls@chakpak.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.