All of lore.kernel.org
 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 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.