On Sat, Feb 22, 2020 at 12:34:03PM +0100, tlaronde%polynum.com@localhost wrote:
On Sat, Feb 22, 2020 at 11:05:51AM +0000, Sad Clouds wrote:
On Sat, 22 Feb 2020 11:43:42 +0100
tlaronde%polynum.com@localhost wrote:
On Sat, Feb 22, 2020 at 08:24:18AM +0000, Sad Clouds wrote:
On Sat, 22 Feb 2020 11:37:35 +1100
MJ <mafsys1234%gmail.com@localhost> wrote:
On 22/02/2020 4:28 am, Sad Clouds wrote:
Hi, is it advisable to NOT enable log option for FFSv2 that
resides on SD card due to flash memory wearing out in those
regions, or does it make no practical difference because of
built-in wear levelling?
How long's a piece of string?
Wear levelling just evens out the wear... surprise. It doesn't
account for the overall wear.
Well the SD card contains a general purpose file system, so I'm
expecting some wear on it as data is written over time (normal
desktop computer use). I wasn't sure if FFSv2 logging would
significantly shorten the life span. But I'm guessing it may not be
such a big issue for quite a few years.
From what I have gathered from infos taken here and there, it will
depend on how much percentage the data is occupying on the SD card. If
there is enough empty room on the SD card, the card is optimized so
that new data is written "elsewhere" so that new writes impact other
sectors. The much you have not used sectors, the less the sectors are
overwritten and thus the longer the card will survive.
The error is taking a card that is too small and fits too closely the
amount of data being retained.
Not sure how this would work. If the card is brand new, then I guess it
knows the memory cell is empty, but once you have filled the card and
then deleted most of the files, file system will mark those blocks of
data as free, but the card doesn't know the data has been deleted. I
don't think there is anything like TRIM command.
It was unclear to me too, from the informations gathered here and there,
what was in the filesystem driver, what was in the protocol and what
was in the controler allowing precisely the card to "know" that some
sectors were actually free or not. I guess that for this to work,
whether the filesystem driver has to not try to be smart about
defragmentation (putting a newly freed range of blocks at the end of
the list of available blocks so that a newly allocated block will be a
brand new one as long as not all blocks have been written) or
to specifically dialog with the card to give it information about freed
blocks and to rely on it to obtain a free block in some range.
And there is also the possibility that the card has a map and that as
long as some sectors have never been written, a sector overwritten too
many times is mapped to another sector not in use, the card having
actually a diminishing size over time. And this will work without much
ado as long as there is enough not used sectors on the card "a" sector
(for the driver) being overwritten more than the maximal count specified
because there are indeed several sectors, materially, used at "this"
address.
FWIW,