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 14:42:03 -0200
From:	Carlos Maiolino <cmaiolino@...hat.com>
To:	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 09:06:45AM -0500, Theodore Ts'o wrote:
> On Mon, Jan 13, 2014 at 11:27:08AM -0200, Carlos Maiolino wrote:
> > I'm not really a big fan of removing more backup metadata blocks
> > than we already have with the sparse_super feature, but, giving the
> > SMR writing system, this might save the filesystem from a lot of
> > fragmentation when updating the backup superblocks.
> 
> Not only that, but the backup superblocks become extra things for the
> SMR subsystem to have to copy around.
> 
> > I'm just wondering if it might not be interesting in still have the
> > backup superblock into the last block group, but I'm not really sure
> > about the concerns it might have when resizing a filesystem. This
> > might add more problems than the benefits :)
> 
> Yes, I thought about putting the backup superblock either at the very
> last block group, or at the very end of the file system (which would
> avoid further fragmentation).  Either way, it adds a lot more
> complications, and realistically, have you ever actually seen a user
> take advantage of a backup superblock other than the one at block
> #32768?
> 
> Still, it is something we could do, if we really thought it would
> help.  My original thought was that keeping things simple was better
> than adding more complexity, especially if the vast majority of users
> would never take advantage of such a feature, and given that everyone
> is trained to know that a backup superblock is always available at
> 32768, so we really want to have one there regardless.  Given that, is
> having a third backup superblock at the end of the disk really going
> to provide that much additional safety?
> 

I agree with you here, after being worked as a frontline support for a few
years, I guess I became too paranoid :)
The first thing that came to my mind when you argued about removing remaining
backup superblocks was about people issuing `dd` commands to wrong places of the
device, and having a copy at the very end of the filesystem is less feasible of
somebody rewrite it than at the beginning (or even at 32768). But as I said, I
agree with you here, too much time I don't see anybody needing other backup SB.

> 							 -Ted
> 
> P.S.  If we want to have extra copies of the backup blocks, we could
> also use e2image to make additional backup copies; we could even a
> future version of mke2fs place a copy of the e2image file at the very
> of the file system, if we really thought it would be helpful later on.
> If we thought it was really required, we should do it now, of course.
> I'm just not entirely sure it's worth the extra hair, either way.  I'm
> curious to hear what other people think.

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

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