Avoid excessive write cycles to block

[Frederick Gotham]

I want to use an SDcard as a circular buffer for storing raw binary data (one byte at a time).

First thing I'll do is format an 4GB SDcard with one FAT32 partition, and then I'll create two files on the partition:
position.bin (size = 1 megabyte )
data.bin (size = ~3.9 gigabytes)

The location and size of these two files on the FAT32 partition will never change.

Data will be written to the file "data.bin" byte after byte after byte, and then when the file is full, it will start again writing at the beginning of the file.

The "current write position" will be a 64-Bit number stored in the file "position.bin". Of course this file only needs to be 8 bytes in size, however I've chosen to make it 1 megabyte for the following reason:

I need to read up on this more, but I think SDcards are written to in 512-byte blocks at a time. In order to avoid wearing out the first block on the SDcard, I will initially store the "current write position" at Byte #0 in the file "position.bin", and then the next time I'll move it to Byte #512, and then next time I'll move it to Byte #1024, then Byte #1536, then Byte #2048.

Does this sound like a good strategy to get as much longevity as possible out of the SDcard?

I won't increment the "current write position" 1 byte at a time, probably more like one megabyte at a time (so the position marker could be 32-Bit).

[Öö Tiib]

On Friday, 14 August 2020 00:19:19 UTC+3, Frederick Gotham wrote:
> I want to use an SDcard as a circular buffer for storing raw binary data (one byte at a time).
>
> First thing I'll do is format an 4GB SDcard with one FAT32 partition, and then I'll create two files on the partition:
> position.bin (size = 1 megabyte )
> data.bin (size = ~3.9 gigabytes)
>
> The location and size of these two files on the FAT32 partition will never change.
>
> Data will be written to the file "data.bin" byte after byte after byte, and then when the file is full, it will start again writing at the beginning of the file.
>
> The "current write position" will be a 64-Bit number stored in the file "position.bin". Of course this file only needs to be 8 bytes in size, however I've chosen to make it 1 megabyte for the following reason:
>
> I need to read up on this more, but I think SDcards are written to in 512-byte blocks at a time. In order to avoid wearing out the first block on the SDcard, I will initially store the "current write position" at Byte #0 in the file "position.bin", and then the next time I'll move it to Byte #512, and then next time I'll move it to Byte #1024, then Byte #1536, then Byte #2048.

The multi-gigabyte SD cards have usually 1024 byte sectors. Also SD card
is removable storage so your software can not know now what type will be
entered 2 years from now. But why you worry? SD card is tiny computer
with flash memory that was usually programmed (usually in C) by
relatively bright guys. You for some reason assume that they were rather
dumb?

>
> Does this sound like a good strategy to get as much longevity as possible out of the SDcard?
>
> I won't increment the "current write position" 1 byte at a time, probably more like one megabyte at a time (so the position marker could be 32-Bit).

What you describe is way more primitive and inefficient version
of wear leveling technology (to even out the sectors used) already
in SD and CF cards. IOW it is already there. By magic.

If you program your own file system for flash that you directly access
then you may want to do something like that. But if I would be your
boss I would buy that code instead of letting you to invent some
kind of ugly hack on that case as well.