public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Mahoney <jeffm@suse.com>
To: David Masover <ninja@slaphack.com>
Cc: Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ReiserFS List <reiserfs-list@namesys.com>,
	Mike Benoit <ipso@snappymail.ca>
Subject: Re: [PATCH] reiserfs: eliminate minimum window size for bitmap searching
Date: Tue, 22 Aug 2006 11:55:24 -0400	[thread overview]
Message-ID: <44EB28EC.50802@suse.com> (raw)
In-Reply-To: <44EB23D9.9000508@slaphack.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Masover wrote:
> Jeff Mahoney wrote:
>>  When a file system becomes fragmented (using MythTV, for example), the
>>  bigalloc window searching ends up causing huge performance problems. In
>>  a file system presented by a user experiencing this bug, the file system
>>  was 90% free, but no 32-block free windows existed on the entire file
>> system.
>>  This causes the allocator to scan the entire file system for each
>> 128k write
>>  before backing down to searching for individual blocks.
> 
> Question:  Would it be better to take that performance hit once, then
> cache the result for awhile?  If we can't find enough consecutive space,
> such space isn't likely to appear until a lot of space is freed or a
> repacker is run.

The problem is that finding the window isn't really a direct function of
free space, it's a function of fragmentation. You could have a 50% full
file system that still can't find a 32 block window by having every
other block used. I know it's an extremely unlikely case, but it
demonstrates the point perfectly.

>>  In the end, finding a contiguous window for all the blocks in a write is
>>  an advantageous special case, but one that can be found naturally when
>>  such a window exists anyway.
> 
> Hmm.  Ok, I don't understand how this works, so I'll shut up.

If the space after the end of the file has 32 or more blocks free, even
without the bigalloc behavior, those blocks will be used.

Also, I think the bigalloc behavior just ultimately ends up introducing
even more fragmentation on an already fragmented file system. It'll keep
contiguous chunks together, but those chunks can end up being spread all
over the disk.

- -Jeff

- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFE6yjsLPWxlyuTD7IRAuT0AJ9ssQafYPW+Gy/E/xN+LKCxamjycwCgqL6P
aUbgXdn+0+K3sJhWGBWtrno=
=NDyT
-----END PGP SIGNATURE-----

  reply	other threads:[~2006-08-22 15:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-22 14:28 [PATCH] reiserfs: eliminate minimum window size for bitmap searching Jeff Mahoney
2006-08-22 15:33 ` David Masover
2006-08-22 15:55   ` Jeff Mahoney [this message]
2006-08-22 20:25     ` David Masover
2006-08-22 21:20       ` Jeff Mahoney
2006-08-23  0:11         ` Andrew Morton
2006-08-23  0:38           ` Jeff Mahoney
2006-08-23  2:46           ` Clay Barnes
2006-08-23  2:49             ` Andrew Morton
2006-08-23  0:07     ` Hans Reiser

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=44EB28EC.50802@suse.com \
    --to=jeffm@suse.com \
    --cc=akpm@osdl.org \
    --cc=ipso@snappymail.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ninja@slaphack.com \
    --cc=reiserfs-list@namesys.com \
    --cc=torvalds@osdl.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