linux-ext4 - Re: Missing JBD2_FEATURE_INCOMPAT

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]

Date:	Thu, 19 Apr 2007 23:03:43 -0600
From:	Andreas Dilger <adilger@...sterfs.com>
To:	Mingming Cao <cmm@...ibm.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: Missing JBD2_FEATURE_INCOMPAT_64BIT in ext4

On Apr 19, 2007  17:41 -0700, Mingming Cao wrote:
> Any concerns about turn on META_BG by default for all new ext4 fs?
> Initially I thought we only need META_BG for support >256TB, so there is
> no rush to turn it on for all the new fs. But it appears there are
> multiple benefits to enable META_BG by default:

I would prefer not to have it default for the first 1TB or so of the
filesystem or so.  One reason is that using META_BG for all of the groups
give us only 2 backups of each group descriptor, and those are relatively
close together.  In the first 1TB we would get 17 backups of the group
descriptors, which should be plenty.

> - enable online resize >2TB

Actually, I don't think the current online resize support for META_BG.
There was a patch last year by Glauber de Oliveira Costa which added
support for online resizing with META_BG, which would need to be updated
to work with ext4.  Also, the usage of s_first_meta_bg in that patch is
incorrect.

> - support >256TB fs 

True, though not exactly pressing, and filesystems can be changed
to add META_BG support at any point.

> - Since metadatas(bitmaps, group descriptors etc) are not put at the
>   beginning of each block group anymore, the 128MB limit(block group size
>   with 4k block size) that used to limit an extent size is removed. 
> - Speed up fsck since metadata are placed closely. 

That isn't really true, even though descriptions of META_BG say this.
There will still be block and inode bitmaps and the inode table.
The ext3 code was missing support for moving the bitmaps/itable outside
their respective groups, and that has not been fixed yet in ext4.

The problem is that ext4_check_descriptors() in the kernel was never
changed to support META_BG, so it does not allow the bitmaps or inode
table to be outside the group.  Similarly, ext2fs_group_first_block()
and ext2fs_group_last_block() in lib/ext2fs also don't take META_BG
into account.

Also, since the extent format supports at most 2^15 blocks (128MB) it
doesn't really make much difference in that regard, though it does help
the allocator somewhat because it has more contiguous space to allocate
from.

> So I am wondering why not make it default?

It wouldn't be too hard to add in support for this I think, and there
is definitely some benefit.  Since neither e2fsprogs nor the kernel
handle this correctly, the placement of bitmaps and inode tables outside
of their respective groups may as well be a separate feature.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
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