Understanding Transaction Capacity
|Top Previous Next|
Discussed in this topic: fd.transactioncapacityremaining.
Fd.transactioncapacityremaining can tell you how many changed sectors the transaction journal can still accommodate. The initial value of the fd.transactioncapacityremaining (just after fd.transactionstart) depends on two factors, whichever is smaller:
The maxjournalsectors allocates the journal area of the flash disk. In this journal area, one sector is always needed for internal housekeeping, while other sectors cache the data sectors changed during the transaction. Therefore, if you want to achieve the maximum journal capacity (16), the journal must have at least 17 sectors in it. It is very important to use the maximum transaction memory capacity. The value of 16 is not random — it guarantees that you will always be able, within a single transaction, to change the data in two different files.
In practice, do set a mach higher journal size. This won't increase transaction memory, but it will prolong the life of the flash IC. Values in the 50-100 range are recommended.
14- PL_FD_STATUS_TRANSACTION_CAPACITY_EXCEEDED error will be generated if transaction capacity is exceeded by performing too many disk write operations within a single transaction. The disk will be dismounted (but not damaged) and all changes to the disk made within this failed transaction will be forgotten.
Disk operations and the number of sectors they may affect
So how many sectors may be changed during various disk operations? The table below provides the worst-case numbers.
* Executing these methods can potentially overflow the transaction journal.
And now, the explanation for the table data. It is based on the material from the Disk Area Allocation Details topic.
Here is how to calculate the X parameter:
Supposing, the flash disk capacity (fd.capacity) is 1000 sectors. The FAT, then, must hold 1000 entries. Each FAT sector can hold 128 entries, so there will be 8 active FAT sectors (X = 8). Do not confuse this with the total number of sectors in the FAT area — it is at least twice this amount (because of sector leveling measures). "8" here represents the number of FAT sectors that are needed at any given time.
Therefore, for the disk with fd.capacity= 1000, executing these methods can potentially change 2+8*2=18 sectors. This is above the maximum journal capacity, which is 16! So, how to avoid 14- PL_FD_STATUS_TRANSACTION_CAPACITY_EXCEEDED error and still use transactions?
And the answer is: do it in stages. The following example deletes a very large file in a "safe" manner:
Not a direct sum total
The worst-case number of sectors that may be changed during a transaction is not the sum total of maximum numbers for each fd. object's method. In the example below, the maximum number of changed sectors is 9, not 10.
In this example, the worst-case number is 10, because we are working with 2 different files and their FRT records could be in different FRT sectors: