From: Theodore Ts'o <tytso@mit.edu>
To: Eric Biggers <ebiggers3@gmail.com>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] mke2fs: fix hugefile creation so the hugefile(s) are contiguous
Date: Tue, 20 Jun 2017 05:31:36 -0400 [thread overview]
Message-ID: <20170620093136.ciiothqlcnoihl53@thunk.org> (raw)
In-Reply-To: <20170619232945.GB76149@gmail.com>
On Mon, Jun 19, 2017 at 04:29:45PM -0700, Eric Biggers wrote:
> Can you also update the mke2fs.conf man page to document under what
> circumstances it can be assumed that the preallocated "hugefiles" will be
> physically contiguous? Currently I don't see any mention of it.
Good point, I'll do that.
> > diff --git a/misc/mk_hugefiles.c b/misc/mk_hugefiles.c
> > - retval = ext2fs_fallocate(fs, falloc_flags, *ino, &inode, goal, 0, num);
> > + retval = ext2fs_extent_open2(fs, *ino, &inode, &handle);
> > if (retval)
> > return retval;
> > - retval = ext2fs_inode_size_set(fs, &inode, num * fs->blocksize);
> > +
> > + lblk = 0;
> > + left = num ? num : 1;
>
> Add a comment explaining why ext2fs_fallocate() isn't sufficient?
Done.
> Alternatively, would it be possible to fix ext2fs_fallocate() instead?
We could possibly add this feature to ext2fs_fallocate(); it would
mean changing extent_fallocate() so that it used one goal block
variable for data blocks, and different goal block variable for extent
tree blocks and to default the goal block variable for the
metadata blocks to be "near the inode".
My preference though is to change the behavior back to the original
1.42 behaviour, since this is regression broke production code. Once
we have this fixed we can always try again to refactor the code after
adding a new feature flag to ext2fs_fallocate().
> This only verifies that the extent tree blocks are in the expected locations.
> How about also verifying that the file is actually physically contigious? If
> storing the full output file is too large it could be done algorithmically, e.g.
> verifying that the following doesn't produce any output:
Yeah, I've already modified the test to store the full output of the
dump_extents of the hugefile in compressed form and then to use zcmp
and zdiff to compare the actual output to the expected out. That
seems to be the simplest way to do things, and doesn't require that we
validate the algorihmic code.
- Ted
next prev parent reply other threads:[~2017-06-20 9:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-19 22:49 [PATCH] mke2fs: fix hugefile creation so the hugefile(s) are contiguous Theodore Ts'o
2017-06-19 23:29 ` Eric Biggers
2017-06-20 9:31 ` Theodore Ts'o [this message]
2017-06-19 23:40 ` Darrick J. Wong
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=20170620093136.ciiothqlcnoihl53@thunk.org \
--to=tytso@mit.edu \
--cc=ebiggers3@gmail.com \
--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).