From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Parisc List <linux-parisc@vger.kernel.org>
Subject: Re: [BUG] mke2fs produces corrupt filesystem if badblock list contains a block under 251
Date: Tue, 02 Jul 2019 17:37:32 -0700 [thread overview]
Message-ID: <1562114252.29304.64.camel@HansenPartnership.com> (raw)
In-Reply-To: <20190702203937.GG3032@mit.edu>
On Tue, 2019-07-02 at 16:39 -0400, Theodore Ts'o wrote:
> On Tue, Jul 02, 2019 at 12:31:34PM -0700, James Bottomley wrote:
> > Actually, this is giving me:
> >
> > mke2fs: Operation not supported for inodes containing extents while
> > creating huge files
> >
> > Is that because it's an ext4 only feature?
>
> That'll teach me not to send out a sequence like that without testing
> it myself first. :-)
Heh, join the club ... it has a very large membership ... I've got a
frequent flier card for it ...
> Yeah, because one of the requirements was to make the file
> contiguous, without any intervening indirect block or extent tree
> blocks, the creation of the file is done manually, and at the time, I
> only implemented it for extents, since the original goal of the goal
> was to create really big files (hence the name of the feature
> "mk_hugefile"), and using indirect blocks would be a huge waste of
> disk space.
I guessed as much.
> It wouldn't be that hard for me to add support for indirect block
> maps, or if you were going to convert things over so that the pa_risc
> 2nd stage boot loader can understand how to read from extents,
> that'll allow this to work as well.
Let me look at it. I think I can just take routines out of lib/ext2fs
and graft them into the IPL, but our own home grown ext2/3 handling
routines are slightly eccentric so it's not as simple as that.
James
next prev parent reply other threads:[~2019-07-03 0:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-01 22:44 [BUG] mke2fs produces corrupt filesystem if badblock list contains a block under 251 James Bottomley
2019-07-02 0:23 ` Theodore Ts'o
2019-07-02 0:53 ` James Bottomley
2019-07-02 17:33 ` Theodore Ts'o
2019-07-02 19:31 ` James Bottomley
2019-07-02 20:39 ` Theodore Ts'o
2019-07-03 0:37 ` James Bottomley [this message]
2019-07-05 16:25 ` Question about ext4 testing: need to produce a high depth extent tree to verify mapping code James Bottomley
2019-07-05 17:39 ` Matthew Wilcox
2019-07-05 18:49 ` James Bottomley
2019-07-05 21:40 ` Darrick J. Wong
2019-07-06 4:02 ` 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=1562114252.29304.64.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=tytso@mit.edu \
/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).