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]
Message-ID: <20140113140645.GC18029@thunk.org>
Date:	Mon, 13 Jan 2014 09:06:45 -0500
From:	Theodore Ts'o <tytso@....edu>
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 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?

							 -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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ