linux-ext4 - Re: [PATCH RFC] Add support for new compat feature "one_backup

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 13 Jan 2014 17:02:50 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Andreas Dilger <adilger@...ger.ca>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH RFC] Add support for new compat feature "one_backup_sb"

On Mon, Jan 13, 2014 at 01:41:27PM -0700, Andreas Dilger wrote:
> 
> Instead of adding a new location for the backup superblock at the
> "end" of the disk (which is subject to change if the filesystem is
> resized), what about using the last group that would otherwise have
> a backup superblock with the "sparse_super" feature?  That means
> resizing the filesystem by some amount won't change the location of
> the backup, and avoids the need to change all of the documentation
> for how to find superblocks.

That doesn't actually reduce the complexity.  The two headaches with
dealing with the resize is (a) when you grow the file system and add
one or more new block groups, you need to release the blocks
associated with backup superblock and block group descriptors, and
then (b) when you shrink a file system and you remove one or more
block groups, you need to relocate blocks where we need to put backup
superblocks in the "new" last block group.

Neither of these is a show stopper, but it's annoying since we need to
implement (a) and (b) in resize2fs, and then in the kernel twice, once
for the old-style online resize, and then again for the meta_bg style
online resize.

If we put the 2nd backup sueprblock in the last location where there
is a sparse_super feature, we still have deal with both of these
issues, and indeed it's actually a bit more of a headache to calculate
the block group which satisfies this constraint.  In addition, it
decreases slihgtly the range of contiguous data blocks.  (Putting the
backup superblock at the very end of the file system is the best from
this perspective, but it increases the complexity headache even more.)

What I'll probably do for now is to simply not support online resize
for the newly renamed "super sparse" feature, since for my use case,
which is for things like SMR disks, we're not going to be resizing
them anyway.  If we want to use this mode for RAID 5 arrays, then we
will have to get the resizing support working for the new "super
sparse" mode.

						- Ted
--
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