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