bd: Tweaked block device API to fit SD cards and FTLs better #4983
Conversation
|
Adopted trim function in the FAT filesystem, however that makes this pr now dependent on #4843 |
| MBED_ASSERT(_ffs[pdrv]->get_read_size() <= _ffs[pdrv]->get_erase_size()); | ||
| MBED_ASSERT(_ffs[pdrv]->get_program_size() <= _ffs[pdrv]->get_erase_size()); | ||
| return ssize; | ||
| } |
There was a problem hiding this comment.
get_erase_size() / get_program_size() / disk_get_sector_size() are bit confusing, please verify my understanding below:
- program size - Can be 1 to 512 bytes (based on device type). Will this be > 512?
- Erase size - Set as program size (Can we set it as sector size instead) = 512 ?
- disk_get_sector_size - Here we are forcing it to be 512, why can't we simply set it as 512? Sector size is for file system and not dependent on device.
There was a problem hiding this comment.
program size - Can be 1 to 512 bytes (based on device type). Will this be > 512?
It could be > 512 though I don't know of any devices currently that go that high.
Erase size - Set as program size (Can we set it as sector size instead) = 512 ?
Are you asking about the get_erase_size function inside the driver? The driver doesn't have a concept of sector size. These functions just report the physical limitations of the device. It's up to the filesystem on top to choose a sector size.
disk_get_sector_size - Here we are forcing it to be 512, why can't we simply set it as 512? Sector size is for file system and not dependent on device.
nor flash specificially needs a sector size of at least 4096 bytes, since it can't erase at <4096 bytes. However, the larger sector size comes with a ram cost, so it's better to use ~512 byte sectors where possible.
| } else { | ||
| DWORD *sectors = (DWORD*)buff; | ||
| DWORD ssize = disk_get_sector_size(pdrv); | ||
| int err = _ffs[pdrv]->trim(sectors[0]*ssize, (sectors[1]-sectors[0]+1)*ssize); |
There was a problem hiding this comment.
Arguments to erase function were start sector, and total size to erase. Please clarify what are the arguments of trim? sectors[0] / sectors[1] what do they contain?
There was a problem hiding this comment.
Ah sure: http://elm-chan.org/fsw/ff/doc/dioctl.html
The sector block is specified by a DWORD array
{<start sector>, <end sector>}
So sectors[0] is the start sector, and sectors[1] is the end sector (inclusive) of the trim operation.
| * This is the number of bytes per cluster. A larger cluster size will decrease | ||
| * the overhead of the FAT table, but also increase the minimum file size. The | ||
| * cluster_size must be a multiple of the nearest power-of-2 of the underlying | ||
| * device's erase_size. If zero, a cluster size will be determined from the |
There was a problem hiding this comment.
Device erase_size can be as less as single block. Cluster size (nearest power of 2 of erase_size 512bytes) will be 1024 bytes and not good value to set.
Cluster size is logical boundary in files system.
AU size on SD cards is not logical boundary, but physical boundary in user area of card, and formatting card with correct AU size gives optimal performance. Setting cluster size equivalent to AU size is recommended for SD cards.
There was a problem hiding this comment.
Ah, I changed this over here
https://github.com/ARMmbed/mbed-os/pull/4843/files#diff-d2c0be70be00c3c1688a6e00f622217bR54
I just haven't rebased this pr yet
|
The dependency was merged, shall this be rebased now? |
This should help with confusion around devices that don't have a physical erase operation, such as SD cards and spinny disks.
|
rebased 👍 |
Result: FAILUREYour command has finished executing! Here's what you wrote!
OutputTest failed! |
|
I assume the failure is not related to this changeset. Please be aware of the timing limits now for testing as we are close to the code freeze, nightly on this only if it is required to get in 5.6, let us know. @mazimkhan uvisor CI did not report the status? |
|
Ah sorry. Can we add a 5.6.1 label? |
Bump |
|
/morph test-nightly |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
OutputAll builds and test passed! |
|
retest uvisor |
The block device API is currently tied very closely to flash devices. This is because flash devices are our primary targets, but it does make porting to other non-flash block devices a bit more confusing than is necessary (this includes SD cards, FTLs, and more ridiculous spinny disks).
These are a few tweaks from offline discussions with @deepikabhavnani that should improve things:
Provide default for erase function
This means the function can simply be omitted from the SD card repo and the block device should behave as expected
Add trim function to provide hints for unused blocks
See https://en.wikipedia.org/wiki/Trim_(computing) for prior art
This allows a filesystem to hint when blocks are no longer in use, and can allow much better wear leveling performance when an FTL is present, such as in SD cards.
relevant range 626256e...geky:bd-trim-erase
dependent on #4843
related PelionIoT/sd-driver#55
cc @deepikabhavnani, @sg-