public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Michael H. Warfield" <mhw@wittsend.com>
To: linux-kernel@vger.kernel.org
Cc: mhw@wittsend.com
Subject: Sync option destroys flash!
Date: Fri, 13 May 2005 12:20:06 -0400	[thread overview]
Message-ID: <1116001207.5239.38.camel@localhost.localdomain> (raw)

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

	Under the right circumstances, even copying a single file to a flash
drive mounted with the "sync" option can destroy the entire drive!

	Now that I have your attention!

	I found this out the hard way.  (Kissed one brand new $70 USD 1GB flash
drive good-bye.)  According to the man pages for mount, FAT and VFAT
file systems ignore the "sync" option.  It lies.  Maybe it use to be
true, but it certainly lies now.  A simple test can verify this.  Mount
a flash drive with a FAT/VFAT file system without the sync option and
writes to the drive go very fast.  Typing "sync" or unmounting the drive
afterwards, takes time as the buffered data is written to the flash
drive.  This is as it should be.  Mount it with the sync option and
writes are really REALLY slow (worse than they should be just from
copying the data through USB) but sync and umount come back immediately
and result in no additional writing to the drive.  [Do the preceding
with only a few files and less than a few meg of data if you value that
flash.]  So...  FAT and VFAT are honoring the sync option.  This is very
VERY bad.  It's bad for floppies, it's bad for hard drives, it's FATAL
for flash drives.

	Flash drives have a limited number of write cycles.  Many many
thousands of write cycles, but limited, none the less.  They are also
written in blocks which are much larger than the "sector" size report
(several K in a physical nand flash block, IRC).

	What happens, with the sync option on a VFAT file system, is that the
FAT tables are getting pounded and over-written over and over and over
again as each and every block/cluster is allocated while a new file is
written out.  This constant overwriting eventually wears out the first
block or two of the flash drive.

	I had lost a couple of flash keys previously, without realizing what
was going on, but what send me off investigating this was when I copied
a 700 Meg file to a brand new 1G USB 2.0 flash memory key in a USB 2.0
slot.  It took over a half an hour to copy to the drive, which really
had me wondering WTF was wrong!  Then, when I went to use the key, I
found the first couple of blocks were totally destroyed.  Read errors
immediately upon insertion.  Then I started digging and found the
hotplug / HAL / fstab-sync stuff on Fedora Core was mounting USB drives
with the "sync" option (if less than 2 Gig).  I knew from previous
experience (CF backup cards in a PDA) that repeated pounding on the FAT
tables would destroy a flash card with a FAT file system.  So I reported
this on the Fedora list.  Someone else noticed that the man pages for
mount state that FAT and VFAT ignore the sync option.  Not so,
obviously...  Copying that 700 Meg file resulted in thousands upon
thousands upon thousands of writes to the FAT table and backup FAT
table.  It simply blew through all the rewrites for those blocks and
burned them up.  Bye bye flash key...

	On a floppy, this would result in an insane amount of jacking around
back and forth between data sectors and the FAT sectors.  In addition to
taking forever, that would shorten the life of the diskettes and the
drive itself, but who cares about floppies any more.  On a real hard
drive, this will cause "head resonances" as the heads go through
constant high speed seeks between the cylinder with the FAT tables and
the data cylinders.  That can't be good, on a continuous basis, for
drive life.  But it's really a disaster for flash memory.  It's going to
cause premature failure in most flash memory, even if it doesn't kill
them right off as it did in my case with a 700 Meg file.

	Can we go back to ignoring "sync" on FAT and VFAT?  I can't see where
it does much good.  You might corrupt a file system if you unplugged it
while dirty but it beats the hell out of physically burning it up and
destroying the drive!

	If it's decided that the FAT and VFAT file systems MUST obey the sync
option then please do something about a special case for the FAT tables!
Sync the data if thou must buti...  Thou shalt not, must not, whack off
on the FAT tables!!!

	Another option would be to only sync the FAT and VFAT file systems upon
close of the file being written or upon close of the last file open on
the file system (fs not busy) but that might not help in the case of a
whole lotta little files...

	I'm also going to file a couple of bug reports in bugzilla at RedHat
but this seems to be a more fundamental problem than a RedHat specific
problem.  But, IMHO, they should never be setting that damn sync flag
arbitrarily.

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com  
  /\/\|=mhw=|\/\/       |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 307 bytes --]

             reply	other threads:[~2005-05-13 16:23 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-13 16:20 Michael H. Warfield [this message]
2005-05-13 17:17 ` Sync option destroys flash! Lennart Sorensen
2005-05-13 17:53   ` Michael H. Warfield
2005-05-13 18:09     ` Lennart Sorensen
2005-05-13 18:21       ` Michael H. Warfield
2005-05-13 18:26         ` Lennart Sorensen
2005-05-13 18:52           ` Flash device types Mark Rustad
2005-05-13 18:53           ` Sync option destroys flash! Michael H. Warfield
2005-05-13 17:58   ` Zan Lynx
2005-05-13 18:13     ` Lennart Sorensen
2005-05-13 18:40 ` Alan Cox
2005-05-13 19:10   ` Michael H. Warfield
2005-05-13 22:00     ` Alan Cox
2005-05-13 22:22       ` Måns Rullgård
2005-05-13 23:24         ` Jon Masters
2005-05-13 23:01       ` Jeffrey Hundstad
2005-05-13 23:27         ` Jon Masters
2005-05-14 10:17       ` Jörn Engel
2005-05-14  1:05   ` Michael H. Warfield
2005-05-17 13:30     ` Lennart Sorensen
2005-05-13 21:25 ` Lee Revell
2005-05-13 22:43   ` Alan Cox
2005-05-15 19:00 ` Denis Vlasenko
2005-05-16  0:23   ` Mark Lord
2005-05-16  9:29     ` David Woodhouse
2005-05-16 16:42       ` Pavel Machek
2005-05-16 13:01     ` Richard B. Johnson
2005-05-16 23:18   ` Helge Hafting
2005-05-18  7:03     ` Denis Vlasenko
2005-05-17  7:59 ` Colin Leroy
     [not found] <43Ldl-NM-25@gated-at.bofh.it>
     [not found] ` <43M9s-1B8-39@gated-at.bofh.it>
     [not found]   ` <43MCx-1UF-27@gated-at.bofh.it>
     [not found]     ` <43MVz-2hL-1@gated-at.bofh.it>
2005-05-13 23:59       ` Robert Hancock
  -- strict thread matches above, loose matches on Subject: below --
2005-05-14  2:43 linux
2005-05-17 13:36 ` Lennart Sorensen
2005-05-17 20:31   ` linux
2005-05-17 20:43     ` Richard B. Johnson
2005-05-18 13:37     ` Lennart Sorensen
     [not found] <43UT5-jT-3@gated-at.bofh.it>
2005-05-14  4:34 ` Robert Hancock
2005-05-18 11:13 linux
2005-05-18 12:01 ` Richard B. Johnson

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=1116001207.5239.38.camel@localhost.localdomain \
    --to=mhw@wittsend.com \
    --cc=linux-kernel@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