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 --]
next 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).