From: "George Spelvin" <linux@horizon.com>
To: linux@horizon.com, tytso@mit.edu
Cc: linux-ext4@vger.kernel.org
Subject: Re: Sign, more experimentation and broken features...
Date: 12 Mar 2013 08:04:25 -0400 [thread overview]
Message-ID: <20130312120425.4665.qmail@science.horizon.com> (raw)
In-Reply-To: <20130312040649.GD18595@thunk.org>
> I'm going to guess there may be problems with using the e2fsck -D
> option with bigalloc. I could imagine potential problems with that,
> and it's probably not something we've explicitly tested.
Ah. I'll see if I can re-create and test that.
> Also, just to check.... all of this was done with the file system
> unmounted, right?
Definitely. I would hope the lack of error message from e2fsck
made that clear, but I suppose it could have been mounted RO.
> The good news is that this appears to be a newly added group, so
> hopefully there was no data lost.
I noticed that, too. I also have the ability to leave this FS alone for
a while, so I haven't touched it yet. Is there some more useful debug
information to be gathered before I start contaminating the scene?
> It may be worth mounting the file system read-only and copying all of
> your data off before you do anything else....
Yeah, I'll have to borrow some additional drives to do that with...
> Also, it looks like there may be some problems with the metadata_csum
> option when resizing, either alone or in combination with bigalloc.
> Please note that I have ___not___ really done a lot of exhaustive
> testing with metadata_csum, since it's not in a released final state
> in e2fsprogs, and I've had lots of other things I've been busy trying
> to make sure is stablized. For example, we are still working on
> fixing various test failures with bigalloc. It's probably good enough
> for fairly simple workloads (mostly using fallocate and direct I/O),
> but there are corner cases which we are still working on fixing.
I've jyst been running it successfully on a few machines since my last round
of complaints, so I figured I'd try a *new* feature as well. :-)
(I would have turned on INLINE_DATA too if I could figure out how to
enable it. Ah, -O inline_data seems to be it.)
Unfortunately, I was stupid and didn't grab the latest e2fsprogs that
includes the bigalloc warnings.
next prev parent reply other threads:[~2013-03-12 12:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-12 3:28 Sign, more experimentation and broken features George Spelvin
2013-03-12 4:06 ` Theodore Ts'o
2013-03-12 12:04 ` George Spelvin [this message]
2013-03-17 17:51 ` George Spelvin
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=20130312120425.4665.qmail@science.horizon.com \
--to=linux@horizon.com \
--cc=linux-ext4@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).