Changes

==== Logs analysis Analysis of the logs and conclusions ====

Please note that this formatting results in a an <code>ext4</code> 4 -kByte block size:

The [https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Blocks ext4 block] '''must not be confused with the e.MMC blocks''', which are 512 bytes as per JEDEC specifications and are addressed according to the [https://en.wikipedia.org/wiki/Logical_block_addressing LBA] scheme.

The analyzed workload is the result of a combination of different tools performing read and write accesses (<code>/mnt/mmc0</code> is the mount point of the partition of interestbeing tested):

The following chart shows how the e.MMC access accesses over time during the execution of the workloadalong with other measurements such as read/write throughput.

It is also possible to extrapolate the latency of the operations. [[File:MISC-TN-017-eMMC-chart3-latency.png|center|thumb|600x600px|Latency]]  Another extremely useful graphical depiction is the chunk size distribution illustrated in . For instance, this chartinformation is often used to understand how efficient the user application is when it comes to optimize the write operations for maximizing the e.MMC lifetime. The pie on the left refers to the read operations, while the other one refers to the write operations. To interpret the result, one needs to take into account how the workload was implemented.

Basically, it makes use of two applications: <code>[https://man7.org/linux/man-pages/man1/dd.1.html dd]</code> and <code>stressapptest</code>. <code>dd</code> was specified to use 4 -kByte data chunks (<code>bs=4k</code>). <code>stressapptest </code> uses 512-byte chunks instead as because the <code>--write-block-size </code> parameter was not used (for more details please refer to the [https://github.com/stressapptest/stressapptest/blob/e6c56d20c0fd16b07130d6e628d0dd6dcf1fe162/src/worker.cc#L2615 source code]). As a result, one would expect that a   4kB (dd) 512B (streassapptest) Questo perché, non essendo specificato il parametro --write-block-size, dovrebbe valere il default: read_block_size_ = kSectorSize; // default 1 sector (the majority of accesses are 512 bytes) write_block_size_ = kSectorSize; // and 4 kByte. The charts clearly show that this assumes read is not the case. Most of the accesses are 512kB. This is a blatant example of how the algorithms of the file systems and write the kernel block size  [[File:MISC-TN-017-eMMC-chart3-latencydriver optimize the accesses.png|center|thumb|600x600px|Latency]]