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
prev parent 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.