linux-ext4 - Re: [PATCH] Add basic BIGALLOC support for cluster-based allocation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <AANLkTinx13sLiOpV=VG1T5JZd4G81fYFLXQRKfXnqsJB@mail.gmail.com>
Date:	Mon, 28 Feb 2011 11:18:28 +0200
From:	Amir Goldstein <amir73il@...il.com>
To:	"Ted Ts'o" <tytso@....edu>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] Add basic BIGALLOC support for cluster-based allocation

On Sun, Feb 27, 2011 at 11:59 PM, Ted Ts'o <tytso@....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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html