Re: FFSv2 log option with SD card

[tlaronde%polynum.com@localhost]

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,
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C