From: Theodore Ts'o <tytso@mit.edu>
To: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH RFC] Add support for new compat feature "one_backup_sb"
Date: Mon, 13 Jan 2014 09:06:45 -0500 [thread overview]
Message-ID: <20140113140645.GC18029@thunk.org> (raw)
In-Reply-To: <20140113132707.GA22358@orion.maiolino.org>
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.
next prev parent reply other threads:[~2014-01-13 14:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-12 3:23 [PATCH RFC] Add support for new compat feature "one_backup_sb" Theodore Ts'o
2014-01-13 13:27 ` Carlos Maiolino
2014-01-13 14:06 ` Theodore Ts'o [this message]
2014-01-13 16:19 ` Theodore Ts'o
2014-01-13 20:41 ` Andreas Dilger
2014-01-13 22:02 ` Theodore Ts'o
2014-01-14 5:54 ` [PATCH v2] Add support for new compat feature "super_sparse" Theodore Ts'o
2014-01-14 11:21 ` Andreas Dilger
2014-01-14 16:08 ` Theodore Ts'o
2014-01-16 20:21 ` Andreas Dilger
2014-01-16 20:54 ` Theodore Ts'o
2014-01-14 18:42 ` Darrick J. Wong
2014-01-13 16:42 ` [PATCH RFC] Add support for new compat feature "one_backup_sb" Carlos Maiolino
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140113140645.GC18029@thunk.org \
--to=tytso@mit.edu \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).