From: Mark Lord <lkml@rtr.ca>
To: Denis Vlasenko <vda@ilport.com.ua>
Cc: mhw@wittsend.com, linux-kernel@vger.kernel.org
Subject: Re: Sync option destroys flash!
Date: Sun, 15 May 2005 20:23:35 -0400 [thread overview]
Message-ID: <4287E807.6070502@rtr.ca> (raw)
In-Reply-To: <200505152200.26432.vda@ilport.com.ua>
All flashcards (other than dumb "smart media" cards) have integrated
NAND controllers which perform automatic page/block remapping and
which implement various wear-leveling algorithms. Rewriting "Sector 0"
10000 times probably only writes once to the first sector of a 1GB card.
The other writes are spread around the rest of the card, and remapped
logically by the integrated controller.
Linux could be more clever about it all, though. Wear-leveling can only
be done efficiently on "unused" or "rewritten" blocks/pages on the cards,
and not so well with areas that hold large static data files (from the point
of view of the flash controller, not the O/S).
If we were really clever about it, then when Linux deletes a file from a
flashcard device, it would also issue CFA ERASE commands for the newly
freed sectors. This would let the card's controller know that it can
remap/reuse that area of the card as it sees fit.
But it's dubious that a *short term* use (minutes/hours) of O_SYNC
would have killed a new 1GB card.
Cheers
next prev parent reply other threads:[~2005-05-16 0:23 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
2005-05-16 0:23 ` Mark Lord [this message]
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=4287E807.6070502@rtr.ca \
--to=lkml@rtr.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=mhw@wittsend.com \
--cc=vda@ilport.com.ua \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.