FDS GC seems not to work

[Haruki Kawakami]

Using SDK 13 FDS, I store 6468 byte, that is 1617 words, including FDS header. Of course this size is total. In detail in byte size, this size consists of

(12(header)+ 576) * 7
(12 + 774) * 1
(12 + 691) * 2
(12 + 144) * 1

I set FDS_VIRTUAL_PAGE_SIZE to 1024 and FDS_VIRTUAL_PAGES to 3.

Then, first write with fds_record_write() is success.

However, second write, that is update, with fds_record_update() fails with FDS_ERR_NO_SPACE_IN_FLASH.

I call fds_gc everytime after fds_record_write () or fds_record_update() call.

I assume that fds_record_update() marks the current record as deleted one and write data to new record area, then calling fds_gc() makes the record area marked as deleted available again.

But when I print out debug log in page_has_space() in fds.c, write_offset of page is only incremented, and FDS doesn't seems to reuse deleted page.

Is my thought correct? If so, this phenomenon is bug? If not, how should I update my data?

Thank you.

[emdi]

Hi,

Running GC after fds_record_write() has no effect.

Running GC after fds_record_update() will delete the 'old' copy of the record, if it succeeds.

To have an 'old' copy of the record the fds_record_update() call must have returned FDS_SUCCESS synchronously and then sent out an FDS_EVT_UPDATE event indicating FDS_SUCCESS. Otherwise, the operation is not performed and thus no 'old' record that can be garbge collected is present in flash.

My understanding is that you are not actually able to create a new, updated copy of a record because the fds_record_update() call returns FDS_ERR_NO_SPACE_IN_FLASH which indicates that there is no space for the new copy, therefore the record can't be updated and the 'old' copy marked as dirty.

Regards, emdi

[Haruki Kawakami]

I got running GC after fds_record_write() has no effect.

Then, I'm noticed that I have omitted description a little.

More detail explanation is below.

For initial write of 6468 byte, I use fds_record_write() for 11 times, and all results are FDS_SUCCESS. Then for next write, that is update, of 6468 byte, I use fds_record_update(). The write and update order is below.

1. (12 + 144) * 1
2. (12 + 691) * 2
3. (12 + 774) * 1
4. (12(header)+ 576) * 7

For 1 and first of 2 update execution, fds_record_update() returns FDS_SUCCESS, then for second of 2 execution, fds_record_update() returns FDS_ERR_NO_SPACE_IN_FLASH.

Then I call fds_gc() and call fds_record_update() again, but it returns FDS_ERR_NO_SPACE_IN_FLASH again.

Does fds_gc() only work when all 4096 byte area are marked as deleted? If so, should I set FDS_VIRTUAL_PAGES to 5 (double for my data)?

[Luis]

Every time you call FDS functions, are you waiting and reading for the interrupt result? Are you using peer manager?

[Haruki Kawakami]

Yes, I am waiting and reading for the result, and confirming result is FDS_SUCCESS. And for second question, Yes I'm using peer manager.

[Luis]

I believe peer manager uses 1 full FDS page by itself, so it is normal that you get NO_SPACE_IN_FLASH when trying to update everything at once, because there is no enough room. But as you state, GC should be able to delete those two records that you already updated and let you update one more... then GC is failing... are you sure there is no record opened at the moment you call gc? please copy here your FDS interrupt handler. Are you reading flash records at any moment? What is your BLE activity?