linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rogier Wolff <R.E.Wolff@BitWizard.nl>
To: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH, RFC 00/12] bigalloc patchset
Date: Mon, 21 Mar 2011 12:31:19 +0100	[thread overview]
Message-ID: <20110321113119.GA16292@bitwizard.nl> (raw)
In-Reply-To: <5427513F-76B9-4315-AC17-4BF35B290B18@dilger.ca>

On Mon, Mar 21, 2011 at 09:55:07AM +0100, Andreas Dilger wrote:

> Unfortunately, the overhead of allocating a whole cluster for every
> index block and every directory is fairly high.  For Lustre it
> matters very little, since there are only a handful of directories
> (under 40) on the data filesystems where this would be used and the
> real directory tree is located on a different metadata filesystem
> which probably wouldn't use this feature, but for most "normal"
> users this overhead may become prohibitive.  That is why I've been
> trying to think of a way to allow sub-cluster allocations for these
> uses.

FYI, one filesystem I know has a neat trick that works well (IMHO). 

Whenever you have a file or a "tail-of-a-file" that is smaller than a
cluster, you allocate it from a special file that contains all
tails-of-files that are a specific size.

That filesystem happened to have 64k clusters and 512byte
tail-file-granularity. So it had 128 files that contained the tails of
all possible differt sizes.

In our case I would suggest using a sequence something like: 
4k, 8k, 12k, 16k, 24k, 32k, 48k 64k, 96k, 128k and so on. 

That way with about 15 tail-files we are reasonably efficient (never
having more than 4k or 33% allocated over the filesize). Also, adding
8k to a 128k file doesn't require moving the whole file from one spot
in the filesystem to another, which would be required if we were to 
enumerate all 4k-multiples up to 1M. 

The higher bits of the block numbers will indicate that it refers to a
tail-block blocknumber, and in which tail-file to look for the
tail-block.

	Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ

  reply	other threads:[~2011-03-21 11:31 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-19 21:28 [PATCH, RFC 00/12] bigalloc patchset Theodore Ts'o
2011-03-19 21:28 ` [PATCH, RFC 01/12] ext4: read-only support for bigalloc file systems Theodore Ts'o
2011-03-21 19:35   ` Lukas Czerner
2011-03-22 17:02     ` Ted Ts'o
2011-03-23 10:28       ` Lukas Czerner
2011-03-19 21:28 ` [PATCH, RFC 02/12] ext4: enforce bigalloc restrictions (e.g., no online resizing, etc.) Theodore Ts'o
2011-03-19 21:28 ` [PATCH, RFC 03/12] ext4: Convert instances of EXT4_BLOCKS_PER_GROUP to EXT4_CLUSTERS_PER_GROUP Theodore Ts'o
2011-03-20 10:26   ` Amir Goldstein
2011-03-21 13:12     ` Ted Ts'o
2011-03-19 21:28 ` [PATCH, RFC 04/12] ext4: Remove block bitmap initialization in ext4_new_inode() Theodore Ts'o
2011-03-19 21:28 ` [PATCH, RFC 05/12] ext4: factor out block group accounting into functions Theodore Ts'o
2011-03-19 21:28 ` [PATCH, RFC 06/12] ext4: split out ext4_free_blocks_after_init() Theodore Ts'o
2011-03-19 21:28 ` [PATCH, RFC 07/12] ext4: bigalloc changes to block bitmap initialization functions Theodore Ts'o
2011-03-19 21:28 ` [PATCH, RFC 08/12] ext4: Convert block group-relative offsets to use clusters Theodore Ts'o
2011-03-19 21:28 ` [PATCH, RFC 09/12] ext4: teach ext4_ext_map_blocks() about the bigalloc feature Theodore Ts'o
2011-03-19 21:28 ` [PATCH, RFC 10/12] ext4: teach ext4_statfs() to deal with clusters if bigalloc is enabled Theodore Ts'o
2011-03-21 20:17   ` Lukas Czerner
2011-03-22 22:09     ` Ted Ts'o
2011-03-19 21:28 ` [PATCH, RFC 11/12] ext4: tune mballoc's default group prealloc size for bigalloc file systems Theodore Ts'o
2011-03-19 21:28 ` [PATCH, RFC 12/12] ext4: enable mounting bigalloc as read/write Theodore Ts'o
2011-03-20 10:33 ` [PATCH, RFC 00/12] bigalloc patchset Amir Goldstein
2011-03-21  8:55 ` Andreas Dilger
2011-03-21 11:31   ` Rogier Wolff [this message]
2011-03-21 13:24   ` Ted Ts'o
2011-03-21 23:42     ` Andreas Dilger
2011-04-05 17:23 ` Coly Li

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=20110321113119.GA16292@bitwizard.nl \
    --to=r.e.wolff@bitwizard.nl \
    --cc=adilger.kernel@dilger.ca \
    --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).