From: Theodore Ts'o <tytso@mit.edu>
To: Eric Sandeen <sandeen@redhat.com>
Cc: "Huang Weller (CM/ESW12-CN)" <Weller.Huang@cn.bosch.com>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
"Juergens Dirk (CM-AI/ECO2)" <Dirk.Juergens@de.bosch.com>
Subject: Re: ext4 filesystem bad extent error review
Date: Fri, 3 Jan 2014 13:06:54 -0500 [thread overview]
Message-ID: <20140103180654.GC4336@thunk.org> (raw)
In-Reply-To: <52C6F944.4030605@redhat.com>
On Fri, Jan 03, 2014 at 11:54:12AM -0600, Eric Sandeen wrote:
> >
> > This call chain only happens if the block device is mounted.
>
> Sure, but I thought that's what they were doing. Maybe I misread.
>
I thought this was in relation to doing what they called a "barrier
test", where you are writing to flash device and then drop power, and
then see if the CACHE FLUSH request was actually honored. (And
whether or not the FTL got corrupted so badly that the device brick's
itself, as does happen for some of the crappier cheap flash out
there.)
But I'm not sure precisely how they implemented their test. It's
possible it was done with the file system mounted. My suggestion was
to make sure that the flash was proof against power drops by doing
this using a raw block device, to remove the variable of the file
system.
Given that they've since reported that they can repro the problem
using soft resets, it doesn't sound like the problem is related to
flash devices not handling powe drops correctly --- although given
that I'm still getting reports of people who have had their SD card
get completely bricked after a power drop event, it's unfortunately
not a solved problem by the flash manufacturers yet.... or rather,
the few (many?) bad apples give all low-end flash a bad name.
- Ted
next prev parent reply other threads:[~2014-01-03 18:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-02 4:59 ext4 filesystem bad extent error review Huang Weller (CM/ESW12-CN)
2014-01-02 18:42 ` Theodore Ts'o
2014-01-03 3:16 ` Huang Weller (CM/ESW12-CN)
2014-01-03 15:48 ` Theodore Ts'o
2014-01-03 16:40 ` AW: " Juergens Dirk (CM-AI/ECO2)
2014-01-06 2:23 ` Huang Weller (CM/ESW12-CN)
2014-01-03 17:23 ` Eric Sandeen
2014-01-03 17:51 ` Theodore Ts'o
2014-01-03 17:54 ` Eric Sandeen
2014-01-03 18:06 ` Theodore Ts'o [this message]
2014-01-03 18:21 ` AW: " Juergens Dirk (CM-AI/ECO2)
2014-01-06 3:53 ` Huang Weller (CM/ESW12-CN)
2014-01-03 16:29 ` AW: " Juergens Dirk (CM-AI/ECO2)
2014-01-03 17:25 ` Eric Sandeen
2014-01-03 18:45 ` AW: " Juergens Dirk (CM-AI/ECO2)
2014-01-03 18:48 ` Eric Sandeen
2014-01-03 18:56 ` AW: " Juergens Dirk (CM-AI/ECO2)
2014-01-06 5:45 ` Huang Weller (CM/ESW12-CN)
2014-01-06 1:44 ` Huang Weller (CM/ESW12-CN)
2014-01-06 5:17 ` Huang Weller (CM/ESW12-CN)
2014-01-06 5:10 ` [Attachment has been removed]RE: " Huang Weller (CM/ESW12-CN)
2014-01-07 9:10 ` Huang Weller (CM/ESW12-CN)
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=20140103180654.GC4336@thunk.org \
--to=tytso@mit.edu \
--cc=Dirk.Juergens@de.bosch.com \
--cc=Weller.Huang@cn.bosch.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
/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).