| 00:00.16 | DocScrutinizer05 | so the trivial controller can always read an erase page into RAM1, wait until all blocks of that page got modified by sequential write() commands from system, then on next write() after that read in the next erasepage into RAM2 with the sector to modify and writre back RAM1_dirty to flash while RAM2 gets modified by further sequential write() cmds |
| 00:01.22 | DocScrutinizer05 | for random access writes stuff soon starts to get cluttered |
| 00:05.47 | DocScrutinizer05 | so to really test TRIM, you's probably want 500 files size 1/500 of SSD capacity each, thentruncate them to 1 byte length each, do trim, and then append to each of them concurrently again |
| 00:06.47 | DocScrutinizer05 | while this is the 100% worst case scenario, in normal operation similar scenarios will happen more often than not, while strictly sequential write is the rather unlikely usecase |
| 00:08.22 | DocScrutinizer05 | a pretty everyday scenario for almost worst case: swap |
| 00:10.47 | DocScrutinizer05 | unless you configure kswapd in a way so it always writes complete aligned erasepage-sized chunks |
| 00:12.39 | DocScrutinizer05 | as soon as you have one byte misalignment, optimum case turns into worst case where every swapped out page involves two erasepage read modify erase write cycles |
| 00:15.29 | DocScrutinizer05 | btw on HDD you see similar effects when your drive always read/modify/writes a complete track instead of on-the-fly insert-writing a single sector |
| 00:16.24 | DocScrutinizer05 | just a page erase on SSD takes much longer that one platter stack spin in a HDD |
| 00:41.01 | DocScrutinizer05 | ((strictly sequential write is the rather unlikely usecase)) also think fragmentation which happens on a FS level and is not visible/understandable by SSD/MMC controller |
| 00:42.20 | DocScrutinizer05 | writing a file sequentially into a fragmented filesystem also is pretty much random access write |
| 00:44.41 | DocScrutinizer05 | note that some SD-card controllers even are known to understand FAT fs and do shadow trim by locating and observing the used blocks table(s) |
| 00:46.34 | DocScrutinizer05 | I don't know how risky that is, I guess they must have implemented quite some heuristics and safeguard monitors to stop this as soon as the slightest doubt about the FS used comes up |
| 02:52.31 | *** join/#maemo-ssu DrCode (~DrCode@5.28.134.3) |
| 04:00.53 | *** join/#maemo-ssu DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 08:02.03 | *** join/#maemo-ssu handaxe (~chatter@c83-248-22-153.bredband.comhem.se) |
| 08:13.39 | *** join/#maemo-ssu LauRoman|Alt (~LauRoman@5-14-0-85.residential.rdsnet.ro) |
| 08:53.49 | *** join/#maemo-ssu dos1 (~dos1@unaffiliated/dos1) |
| 08:54.09 | *** join/#maemo-ssu Sicelo (Sicelo@unaffiliated/sicelo) |
| 08:54.09 | *** join/#maemo-ssu NIN101 (~core@mail2.quitesimple.org) |
| 09:23.01 | ShadowJK | I've always wanted to have this on my phones: https://lwn.net/Articles/518988/ |
| 09:28.22 | *** join/#maemo-ssu handaxe (~chatter@c83-248-22-153.bredband.comhem.se) |
| 10:18.17 | *** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali) |
| 11:01.36 | *** join/#maemo-ssu merlin1991 (~merlin@Maemo/community/cssu/merlin1991) |
| 11:44.54 | *** join/#maemo-ssu dafox (~dafox@2a02:a448:c25a:0:decf:5ea9:e960:80dc) |
| 12:52.50 | *** join/#maemo-ssu dafox (~dafox@2a02:a448:c25a:0:decf:5ea9:e960:80dc) |
| 13:07.20 | DocScrutinizer05 | hehe > It seems that as hardware gets smarter, we need to make even more clever software to manage that "smartness"<< |
| 13:10.34 | DocScrutinizer05 | hmmm >>One area of difficulty is that the shape of an f2fs (such as section and zone size) needs to be tuned to the particular flash device and its FTL; vendors are notoriously secretive about exactly how their FTL works. f2fs also requires that the flash device is comfortable having six or more concurrently "open" write areas.<< |
| 13:31.52 | DocScrutinizer05 | 6 yeafrs old? |
| 13:31.57 | DocScrutinizer05 | years even |
| 13:32.22 | DocScrutinizer05 | oh nope, only 4 |
| 15:38.33 | ShadowJK | I have some cards that are comfortable with 12 open areas |
| 15:38.51 | ShadowJK | In any case, 6 open areas is always better than random |
| 15:40.12 | kerio | hm |
| 15:40.38 | kerio | can we replace the internal eMMC with something based on ram? |
| 15:40.53 | kerio | surely making things non-volatile is harder |
| 15:57.47 | bencoh | ? |
| 17:40.03 | DocScrutinizer05 | kerio: I'm searching for mixed RAM/flash chips with a sincle storage interface (aka ramdisk) since ages, nothing found so far |
| 17:40.13 | DocScrutinizer05 | single* |
| 17:42.21 | DocScrutinizer05 | I mean, how hard could it be to implement one-plus GB RAM buffer in FTL and operate it in a dedicated overlay mode where you define a start address where buffer is used instead of ever writing back stuff to flash? |
| 17:43.36 | kerio | and then you remove the flash |
| 17:43.38 | DocScrutinizer05 | FTLs already implement write protect afaik |
| 17:44.27 | DocScrutinizer05 | I would prefer still keeping flash in same chip behind same interface/bus |
| 17:45.07 | kerio | but who cares about flash |
| 17:45.15 | DocScrutinizer05 | everybody? |
| 17:45.18 | kerio | we have microSDs for that |
| 19:31.23 | *** join/#maemo-ssu LauRoman|Alt (~LauRoman@5-14-0-85.residential.rdsnet.ro) |
| 21:01.14 | ShadowJK | Which brings us back to microsd being slow unless accessed sequentially, which applies mostly only to cameras |
| 21:09.41 | kerio | well, a RAM microsd would be very fast too |
| 21:33.32 | NIN101 | athome |
| 21:33.59 | NIN101 | sorry, wrong chan |
| 21:47.01 | *** join/#maemo-ssu trx (ns-team@devbin/founder/trx) |