linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Albrecht Dreß" <albrecht.dress@arcor.de>
To: Benjamin LaHaise <bcrl@kvack.org>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: VFAT: slow fs corruption? [long]
Date: Thu, 26 Apr 2007 19:37:54 +0200	[thread overview]
Message-ID: <1177609074l.3249l.1l@antares.localdomain> (raw)
In-Reply-To: <20070418230027.GD13621@kvack.org> (from bcrl@kvack.org on Thu Apr 19 01:00:27 2007)

[-- Attachment #1: Type: text/plain, Size: 1870 bytes --]

Hi Ben!

Thanks a lot for your comments, and sorry for the late reply, I did more tests  
in the meantime...

Am 19.04.07 01:00 schrieb(en) Benjamin LaHaise:
> On Wed, Apr 18, 2007 at 07:58:40PM +0200, Albrecht Dreß wrote:
> > - Are there known issues with VFAT in 2.6.11 which might lead to the >  
> observed problems?  Were they fixed?
> > - Is it possible to change the block size in ext2 to 16k (to match the  
> SD > card's erase block size)?
> 
> Flash cards tend to be rather flaky given that they are low cost  
> consumergrade commodities these days.  I would recommend getting a new card  
> firstand seeing if you can still replicate the problem.

I am afraid my explanation was not completely clear: I reformatted the *same*  
card which gave a lot of VFAT errors with ext2 and ran the test again.  Up to  
now, I filled the card several times and erased it, without any problem.  Only  
after killing (switch power off) the system in mid-air, I had a non-clean fs  
and one broken file (which is not surprising, afaik), giving input/output  
errors when I tried to read it.

So my first observation, that VFAT corrupts "somehow", but ext2 doesn't, still  
seems to be valid!

> Out of the box, I've had to replace 2 of 8 flash cards in the last 6 months  
> when they showed similiarly eerie data corruption when files disappeared.

Yes, I know... Unfortunately, it's not possible to get reliable data about the  
achievable life time.

> Doing an md5sum on the device 2 times in a row and getting back different  
> results is Not Good.

Good idea - will be the next check!

Thanks, Albrecht.


--
  Albrecht Dreß  -  Johanna-Kirchner-Straße 13  -  D-53123 Bonn (Germany)
        Phone (+49) 228 6199571  -  mailto:albrecht.dress@arcor.de
   GnuPG public key:  http://www.mynetcologne.de/~nc-dreszal/pubkey.asc

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

      reply	other threads:[~2007-04-26 17:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-18 17:58 VFAT: slow fs corruption? [long] Albrecht Dreß
2007-04-18 23:00 ` Benjamin LaHaise
2007-04-26 17:37   ` Albrecht Dreß [this message]

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=1177609074l.3249l.1l@antares.localdomain \
    --to=albrecht.dress@arcor.de \
    --cc=bcrl@kvack.org \
    --cc=linux-fsdevel@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).