From: Theodore Ts'o <tytso@mit.edu>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 12/12] mke2fs: allow metadata blocks to be at the beginning of the file system
Date: Tue, 21 Jan 2014 01:23:51 -0500 [thread overview]
Message-ID: <20140121062351.GA23185@thunk.org> (raw)
In-Reply-To: <ACF77779-7A44-4ED7-BC49-7658A8DF8514@dilger.ca>
On Mon, Jan 20, 2014 at 04:25:23PM -0700, Andreas Dilger wrote:
> The "packed_meta_blocks" appears to be equivalent to setting flex_bg
> to some large enough factor that all the block and inode bitmaps are
> at the start of the filesystem?
It's not the same thing, unfortunately, because of how we make room
for the file system to grow and so require extra room for potential
new block groups. Try running "mke2fs -t ext4 -G 262144 /tmp/foo.img
1T" and look at the gaps between the allocation bitmaps and the inode
table using dumpe2fs.
> It would probably be better to align
> the inode and block bitmaps and inode table on a multiple of
> s_raid_stride (will this be used to align on SMR erase blocks?) so
> that rewrites are at least somewhat efficient and aligned? That would
> also allow reserving some room in the flex_bg packing to allow for
> filesystem resizing.
Given these blocks are written using random 4k writes, I don't think
any kind of alignment is going to be worth it.
> It would also be useful to allow setting the journal goal block
> directly, instead of journal_location_front only allowing to specify
> goal == 0 (i.e. add "-E journal_start_goal=N" instead of adding
> "-E journal_location_front", which implied by packed_meta_blocks).
> I've wanted to be able to do this for a long time, but the stumbling
> block is that write_journal_inode() doesn't have any parameter to
> specify the goal journal block without storing it in the superblock.
> I suppose it would be possible to pass the journal goal block in
> s_jnl_blocks[0..1] or something?
Hmm, yes, adding a flag which indicates that the starting block should
be passed in s_jnl_blocks[0] is a good idea.
- Ted
next prev parent reply other threads:[~2014-01-21 6:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-20 5:54 [PATCH 00/12] e2fsprogs mke2fs optimizations and new features Theodore Ts'o
2014-01-20 5:54 ` [PATCH 01/12] libext2fs: fix off-by-one bug in ext2fs_extent_insert() Theodore Ts'o
2014-01-20 5:54 ` [PATCH 02/12] libext2fs: clean up generic handling of ext2fs_find_first_{set,zero}_*() Theodore Ts'o
2014-01-20 5:54 ` [PATCH 03/12] libext2fs: build tst_bitmaps with rep invariants checking enabled Theodore Ts'o
2014-01-20 5:54 ` [PATCH 04/12] libext: optimize find_first_set() for bitarray-based bitmaps Theodore Ts'o
2014-01-20 5:54 ` [PATCH 05/12] libext2fs: optimize find_first_{zero,set}() for red-black tree based bitmaps Theodore Ts'o
2014-01-20 5:54 ` [PATCH 06/12] libext2fs: further clean up and rename check_block_uninit Theodore Ts'o
2014-01-20 20:17 ` Darrick J. Wong
2014-01-20 5:54 ` [PATCH 07/12] libext2fs: add ext2fs_block_alloc_stats_range() Theodore Ts'o
2014-02-13 21:50 ` Darrick J. Wong
2014-01-20 5:54 ` [PATCH 08/12] libext2fs: optimize ext2fs_allocate_group_table() Theodore Ts'o
2014-01-20 5:54 ` [PATCH 09/12] libext2: optimize ext2fs_new_block2() Theodore Ts'o
2014-01-20 21:52 ` Andreas Dilger
2014-01-21 15:54 ` Theodore Ts'o
2014-01-20 5:54 ` [PATCH 10/12] mke2fs: optimize fix_cluster_bg_counts() Theodore Ts'o
2014-01-20 5:54 ` [PATCH 11/12] Add support for new compat feature "sparse_super2" Theodore Ts'o
2014-01-20 21:49 ` Andreas Dilger
[not found] ` <alpine.DEB.2.10.1402051559390.16807@tglase.lan.tarent.de>
2014-02-05 16:17 ` Theodore Ts'o
2014-01-20 5:54 ` [PATCH 12/12] mke2fs: allow metadata blocks to be at the beginning of the file system Theodore Ts'o
2014-01-20 16:30 ` Theodore Ts'o
2014-01-20 23:25 ` Andreas Dilger
2014-01-21 6:23 ` Theodore Ts'o [this message]
2014-01-23 21:28 ` Andreas Dilger
2014-01-20 16:30 ` [PATCH 00/12] e2fsprogs mke2fs optimizations and new features Theodore Ts'o
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=20140121062351.GA23185@thunk.org \
--to=tytso@mit.edu \
--cc=adilger@dilger.ca \
--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).