linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Albrecht Dreß" <albrecht.dress@arcor.de>
To: linux-fsdevel@vger.kernel.org
Subject: VFAT: slow fs corruption? [long]
Date: Wed, 18 Apr 2007 19:58:40 +0200	[thread overview]
Message-ID: <1176919129l.3289l.0l@antares.localdomain> (raw)

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

Hi all,

first, please excuse me if this is a very dump question...

I use Linux (inter alia) on an ARM9 system which is attached to a  
measurement device.  The device produces a new data set of ~10 kByte about  
every 20 seconds, and the ARM system stores the data on a 1GB SD card  
attached to it.  The kernel is unfortunately rather old - 2.6.11,  
including several vendor (Digi) supplied drivers.  I didn't have time yet  
to port them all to a recent kernel.

My first approach was to use the SD card with a VFAT file system on it, as  
such cards usually come pre-formatted with it and as the VFAT cluster size  
of 16k matches the erase block size of the card, which should help its  
built-in wear leveller to do its job.

After some time, though, I noticed that several files with measurement  
data were empty, although the directory indicated that they were not.  The  
system was not switched off, and I always call sync() after producing a  
new file.  Running dosfsck on the file system, I got several errors like

   File size is 13978 bytes, cluster chain length is 0 bytes.
   Truncating file to 0 bytes.

or

Cluster 0 out of range (4849729 > 247450). Setting to EOF.
Orphaned long file name part "5d"

My first idea was that the (Digi supplied) MMC driver is somewhat broken.   
Just to check that, I re-formatted the SD card with ext2, and ran the test  
again - and all files looked fine!  Called "e2fsck -f" - no problems with  
the file system.  That seems to indicate that the MMC layer /does/  
actually work.

Questions:
- Is the conclusion correct that the problem seems to be in the VFAT part,  
not in the MMC layer?
- 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)?

Thanks in advance for any help,
Cheers,
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-18 18:17 UTC|newest]

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

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=1176919129l.3289l.0l@antares.localdomain \
    --to=albrecht.dress@arcor.de \
    --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).