From: Arnd Bergmann <arnd@arndb.de>
To: Tim Soderstrom <tim@moocowproductions.org>
Cc: Alan Piszcz <ap@solarrain.com>,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
Justin Piszcz <jpiszcz@lucidpixels.com>,
xfs@oss.sgi.com
Subject: Re: 2.6.38: XFS/USB/HW issue, or failing USB stick?
Date: Fri, 18 Mar 2011 16:59:46 +0100 [thread overview]
Message-ID: <201103181659.46558.arnd@arndb.de> (raw)
In-Reply-To: <30463798-7ACB-4248-8CDC-CEFCB6ABC0BE@moocowproductions.org>
On Friday 18 March 2011, Tim Soderstrom wrote:
> >
> > However, after some amount of time, the errors occur below, is this USB
> > stick failing? Since it has no SMART, is there any other way to verify
> > the 'health' of a USB stick?
>
> What prompted you to go with XFS over, say, ext2? The journal will generally
> cause quite a bit more writes onto your USB device. I use ext2 on my CF card
> in my NAS for that reason (the spinning media is on XFS of course). I know
> that's not an answer to your problem but thought I would add it as a suggestion :)
Using ext2 on flash media instead of ext3 or other file systems is
recommended a lot, but the situation is actually much more complex.
In https://lwn.net/Articles/428584/, I explain how these things work
under the cover. For a drive that can only have very few erase blocks
open, using a journaled file system will always mean thrashing, but
for drives with more open erase blocks, it's probably better to
use a journal than not.
I still need to do simulations to figure out how this exactly
ends up on various file systems, and I had not considered XFS
so far.
Getting back to the rogiinal question, I'd recommend testing the
stick by doing raw accesses instead of a file system. A simple
dd if=/dev/sdX of=/dev/zero iflag=direct bs=4M
will read the entire stick and report any errors. The corresponding
dd of=/dev/zero of=/dev/sdX oflag=direct bs=4M
writes the entire stick. Some media won't report errors on write,
though, so this might not help you at all.
I'm also interested in results from flashbench
(git://git.linaro.org/people/arnd/flashbench.git, e.g. like
http://lists.linaro.org/pipermail/flashbench-results/2011-March/000039.html)
That might help explain how the stick failed.
Arnd
Arnd
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Tim Soderstrom <tim@moocowproductions.org>
Cc: Justin Piszcz <jpiszcz@lucidpixels.com>,
linux-usb@vger.kernel.org, xfs@oss.sgi.com,
linux-kernel@vger.kernel.org, Alan Piszcz <ap@solarrain.com>
Subject: Re: 2.6.38: XFS/USB/HW issue, or failing USB stick?
Date: Fri, 18 Mar 2011 16:59:46 +0100 [thread overview]
Message-ID: <201103181659.46558.arnd@arndb.de> (raw)
In-Reply-To: <30463798-7ACB-4248-8CDC-CEFCB6ABC0BE@moocowproductions.org>
On Friday 18 March 2011, Tim Soderstrom wrote:
> >
> > However, after some amount of time, the errors occur below, is this USB
> > stick failing? Since it has no SMART, is there any other way to verify
> > the 'health' of a USB stick?
>
> What prompted you to go with XFS over, say, ext2? The journal will generally
> cause quite a bit more writes onto your USB device. I use ext2 on my CF card
> in my NAS for that reason (the spinning media is on XFS of course). I know
> that's not an answer to your problem but thought I would add it as a suggestion :)
Using ext2 on flash media instead of ext3 or other file systems is
recommended a lot, but the situation is actually much more complex.
In https://lwn.net/Articles/428584/, I explain how these things work
under the cover. For a drive that can only have very few erase blocks
open, using a journaled file system will always mean thrashing, but
for drives with more open erase blocks, it's probably better to
use a journal than not.
I still need to do simulations to figure out how this exactly
ends up on various file systems, and I had not considered XFS
so far.
Getting back to the rogiinal question, I'd recommend testing the
stick by doing raw accesses instead of a file system. A simple
dd if=/dev/sdX of=/dev/zero iflag=direct bs=4M
will read the entire stick and report any errors. The corresponding
dd of=/dev/zero of=/dev/sdX oflag=direct bs=4M
writes the entire stick. Some media won't report errors on write,
though, so this might not help you at all.
I'm also interested in results from flashbench
(git://git.linaro.org/people/arnd/flashbench.git, e.g. like
http://lists.linaro.org/pipermail/flashbench-results/2011-March/000039.html)
That might help explain how the stick failed.
Arnd
Arnd
next prev parent reply other threads:[~2011-03-18 15:57 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-18 15:08 2.6.38: XFS/USB/HW issue, or failing USB stick? Justin Piszcz
2011-03-18 15:08 ` Justin Piszcz
2011-03-18 15:19 ` Tim Soderstrom
2011-03-18 15:19 ` Tim Soderstrom
2011-03-18 15:59 ` Arnd Bergmann [this message]
2011-03-18 15:59 ` Arnd Bergmann
2011-03-18 16:20 ` Tim Soderstrom
2011-03-18 16:20 ` Tim Soderstrom
2011-03-18 17:45 ` Justin Piszcz
2011-03-18 17:45 ` Justin Piszcz
2011-03-18 19:10 ` Arnd Bergmann
2011-03-18 19:10 ` Arnd Bergmann
2011-03-18 19:26 ` Justin Piszcz
2011-03-18 19:26 ` Justin Piszcz
2011-03-18 19:33 ` Arnd Bergmann
2011-03-18 19:33 ` Arnd Bergmann
2011-03-18 19:51 ` Justin Piszcz
2011-03-18 19:51 ` Justin Piszcz
2011-03-18 20:11 ` Arnd Bergmann
2011-03-18 20:11 ` Arnd Bergmann
2011-03-18 17:45 ` Justin Piszcz
2011-03-18 17:45 ` Justin Piszcz
2011-03-18 15:39 ` Alan Stern
2011-03-18 15:39 ` Alan Stern
2011-03-18 17:47 ` Justin Piszcz
2011-03-18 17:47 ` Justin Piszcz
2011-03-18 19:26 ` Alan Stern
2011-03-18 19:26 ` Alan Stern
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=201103181659.46558.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=ap@solarrain.com \
--cc=jpiszcz@lucidpixels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=tim@moocowproductions.org \
--cc=xfs@oss.sgi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.