public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Denis Vlasenko <vda@ilport.com.ua>
To: mhw@wittsend.com, linux-kernel@vger.kernel.org
Subject: Re: Sync option destroys flash!
Date: Sun, 15 May 2005 22:00:26 +0300	[thread overview]
Message-ID: <200505152200.26432.vda@ilport.com.ua> (raw)
In-Reply-To: <1116001207.5239.38.camel@localhost.localdomain>

On Friday 13 May 2005 19:20, Michael H. Warfield wrote:
> 	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.

What we really need, is a less thorough version of O_SYNC.
O_SYNC currently guarantees that when syscall returns, data
is on media (or at least in disk drive's internal cache :).

This is exactly what really paranoid people want.
Journalling labels, all that good stuff.

But there are many cases where people just want to say
'write out dirty data asap for this device', so that
I can copy files to floppy, wait till it stops making
noise, and eject a disk. Samr for flash if it has write
indicator (mine has a diode).

The difference from O_SYNC is that in this O_LAZY_SYNC mode
writes return early, just filling pagecache, but writeout
is started immediately and continues until there is no dirty
O_LAZY_SYNC data.

This mode won't eat flash as fast as O_SYNC does.
--
vda


  parent reply	other threads:[~2005-05-15 19:00 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-13 16:20 Sync option destroys flash! Michael H. Warfield
2005-05-13 17:17 ` 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 [this message]
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=200505152200.26432.vda@ilport.com.ua \
    --to=vda@ilport.com.ua \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhw@wittsend.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox