On 10/30/2019 07:56, Theo wrote:
> I'm not convinced by this methodology:
>
> - you're writing files not blocks.  The filesystem is almost
> certainly doing things behind the scenes (eg caching data, coalescing
> writes, updating metadata when it feels like it) that mean you can't
> see what's really going on.

No you can't but then you can't ever with an operating system.

> - I don't see you syncing,  forcing cached writes to complete.
> (particularly an issue if the size of writes is less than the memory
> size)

Not sure what you mean by syncing but the files are closed which should
force the OS to flush the write buffers.  In any case the Pi only has
500MB of memory so the OS would have to flush sooner or later.

> - write amplification will expand writes to the native block size
> (some power of two).  409,600 bytes isn't a power of two, so you
> might end up actually writing (for instance) 512KiB.  So in that
> instance your write count would be low by 20%.  If your writes aren't
> aligned with blocks, you could actually be writing 1MiB.

The OS block size is 4096 bytes.  Not sure about the actual card.  I
picked 10 times the OS block size as that created about 24000 files on
the a 16GB card.  Maybe more files is better, I don't know.

> - the data is eminently compressible.  You didn't tell us the FS, but
> some will compress behind the scenes (not if it's FAT though).

The file system is ext4.  The file size reported by the OS is 409600 bytes.

> - some bad SD cards increase wear levelling for the area where the
> FAT is stored.  You won't observe the effects of that, or conversely
> wearing out the FAT faster.

I'm not writing to the FAT partition.

> - the usable space doesn't shrink due to the number of dead blocks.
> You formatted the thing as a 32GB partition, and it'll stay as a 32GB
> partition, even if some of those writes eventually fail.  It might
> get marked as read-only eventually, but it'll never shrink to a 31GB
> partition.  I'm not sure if there's a way to read the number of dead
> blocks like there is on a SATA device.

I don't know.  That is one of the reasons I tried this.

> Practically, to be useful something like this needs to work at the
> block not file level.

The original discussion was about log files and journaling killing the
SD card from too many writes.  So I devised this experiment with all its
limitations to attempt to kill an SD card by writing to it.

I would love to hear some practical suggestions on how to improve the
experiment.

> Theo
>

Stats as of this morning:

2019/10/30 08:47:10
Usable Space: 11028582400
Block Size: 4096
FileSize: 409600
Files: 24232
Files Created: 230654
Ones Writes: 230653
Zeros Writes: 226492
Files Deleted: 218655
Delete Failures: 0
IOExceptions: 0
Total Bytes Written: 187246592000
Processor Temperature: temp=43.5'C



--

Knute Johnson

--- SoupGate-Win32 v1.05