From: Amir Goldstein <amir73il@gmail.com>
To: "Ted Ts'o" <tytso@mit.edu>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] Add basic BIGALLOC support for cluster-based allocation
Date: Mon, 28 Feb 2011 11:18:28 +0200 [thread overview]
Message-ID: <AANLkTinx13sLiOpV=VG1T5JZd4G81fYFLXQRKfXnqsJB@mail.gmail.com> (raw)
In-Reply-To: <20110227215947.GI2924@thunk.org>
On Sun, Feb 27, 2011 at 11:59 PM, Ted Ts'o <tytso@mit.edu> wrote:
> On Sat, Feb 26, 2011 at 09:20:55AM +0200, Amir Goldstein wrote:
>> Just to be clear, my alternative suggestion to on-disk format change was:
>>
>> __u32 s_log_block_size; /* Block size */
>> - __s32 s_log_frag_size; /* Fragment size */
>> + __s32 s_log_cluster_size; /* Allocation cluster size */
>> - __u32 s_blocks_per_group; /* # Blocks per group */
>> + __u32 s_clusters_per_group; /* # Clusters per group */
>> - __u32 s_frags_per_group; /* # Fragments per group */
>> + __u32 s_blocks_per_group; /* # Blocks per group */
>> __u32 s_inodes_per_group; /* # Inodes per group */
>>
>> This way, old kernels see a sane value in what used to be
>> s_blocks_per_group (32K) and new kernels (even without the BIGALLOC
>> feature) make sure to write correct values in both new
>> s_blocks_per_group and s_clusters_per_group (old s_blocks_per_group)
>
> Unfortunately, that's likely to confuse old kernels even more, since
> s_blocks_per_group is used to calculate the number of block groups,
> i.e. s_blocks_count / s_blocks_per_group. In BIGALLOC mode, the
> number of block groups go down, and so if we change s_blocks_per_group
> to s_clusters_per_group, it's likely to cause much mischief, for
> example in ext4_check_descriptors().
>
I see..., I guess if we bite the bullet and "waste" an alloc cluster for every
block bitmap and every inode bitmap, than we could also "waste" some disk
space on dummy group descriptors to leave old kernels in blissful ignorance
(mischief rules!).
Another comment about the design:
It only states that ext4_map_blocks() and downstream functions need to be
aware of the new allocation rules, but I suspect that ext4_truncate() and
downstream functions will also need to take the new rules into account
(i.e. don't 'free' a cluster until all blocks have been freed).
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2011-02-28 9:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-26 2:50 [PATCH] Add basic BIGALLOC support for cluster-based allocation Theodore Ts'o
2011-02-26 2:50 ` [PATCH] ext4: fix compile warnings with EXT4FS_DEBUG enabled Theodore Ts'o
2011-02-26 7:20 ` [PATCH] Add basic BIGALLOC support for cluster-based allocation Amir Goldstein
2011-02-27 21:59 ` Ted Ts'o
2011-02-28 9:18 ` Amir Goldstein [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='AANLkTinx13sLiOpV=VG1T5JZd4G81fYFLXQRKfXnqsJB@mail.gmail.com' \
--to=amir73il@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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).