Why does 'CreateFileTransacted' function return ERROR_TRANSACTION_NOT_ACTIVE(6701L)？

Question

I am making some programs using 'Transaction NTFS'.

The accident like the below has caught me.

1)　start transaction by 'CreateTransaction'.
2)　make one directory in 'D:' drive by 'CreateDirectoryTransacted'.
3)　attempt to make 1000000 files (size:1024byte@file) by 'CreateFileTransacted'
　　into the directoty of 2).
4)　after making many files(over 30000 files),
　　'CreateFileTransacted' function returns ERROR_TRANSACTION_NOT_ACTIVE(6701L).

OS:Windows Server 2008R2

The transaction does not end.
But it shows that 'TRANSACTION' is NOT ACTIVE.

Does anybody tell me the reason or cause about the above？

An additional information I have is the below(the result of command 'fsutil resource info').

D:\>fsutil resource info d:
RM Identifier: 28F9B365-089F-11DE-9770-00155D8B4F2A
KTM Log Path for RM: \Device\HarddiskVolume3\$Extend\$RmMetadata\$TxfLog\$TxfLo
g::KtmLog
Space used by TOPS: 1 Mb
TOPS free space: 100%
RM State: Active
Running transactions: 0
One phase commits: 0
Two phase commits: 0
System initiated rollbacks: 1
Age of oldest transaction: 00:00:00
Logging Mode: Simple
Number of containers: 4
Container size: 10 Mb
Total log capacity: 40 Mb
Total free log space: 25 Mb
Minimum containers: 2
Maximum containers: 4
Log growth increment: 2 container(s)
Auto shrink: Not enabled

Does the configuration of loggin have any bad setting?

Answer 1

This happened because the log filled up.  From the fsutil output I can see that you apparently changed the log defaults to only allow 4 containers (or you're running on a very small volume; TxF automatically scales the log down on small volumes).  I mentioned previously (in http://social.msdn.microsoft.com/Forums/en-US/windowstransactionsprogramming/thread/4ad62c76-3e70-46b3-b2bd-e8754f7e4079) that the defaults should be left alone, because as I said, "the smaller the log, the fewer operations you can perform in a transaction before the log fills up and the transaction is forced to abort".  This is what happened here (note the "System initiated rollbacks" is 1 in the fsutil output, meaning that the system aborted your transaction).

When the log fills up the system has to get log space to allow further transacted activity to take place.  To do that it starts aborting transactions, starting with the oldest (i.e. longest-running) one first.  In your case, the log is restricted to a maximum size of 4 10 MB containers (i.e. it can never be bigger than 40 MB).  Each time you created a new file in your transaction a log record was written, consuming a bit of log space.  Eventually the small log filled up, and TxF began aborting transactions to reclaim log space.  Your transaction was aborted.  Since the transaction is was aborted, subsequent attempts to call CreateFileTransacted with that transaction fail with ERROR_TRANSACTION_NOT_ACTIVE, because the transaction has ended.

---

Christian [MSFT]

Answer 2

Mr.Allred, Thank you so much for answer of yours.

＞From the fsutil output I can see that you apparently changed the log defaults
＞to only allow 4 containers (or you're running on a very small volume;
＞TxF automatically scales the log down on small volumes). 

I take the latter case. I take the logical volume (D:) of 500MB.

＞Each time you created a new file in your transaction a log record was written,
＞consuming a bit of log space. Eventually the small log filled up, and TxF began
＞aborting transactions to reclaim log space.

I couldn't accept your intention.

Could you take confirmation about the API executions and these results
that I take？

＞1)　start transaction by 'CreateTransaction'.
＞2)　make one directory in 'D:' drive by 'CreateDirectoryTransacted'.
＞3)　attempt to make 1000000 files (size:1024byte@file) by 'CreateFileTransacted'
＞　　into the directoty of 2).
＞4)　after making many files(over 30000 files),
＞　　'CreateFileTransacted' function returns ERROR_TRANSACTION_NOT_ACTIVE(6701L).

I describe about 4) into details.
4-1)　The 299999'th "CreateDirectoryTransacted" API call returns success(TRUE).
4-2)　The 300000'th "CreateDirectoryTransacted" API call returns failure(FALSE).

In the time of 4-1), I imagine the log does'nt fill up.
Because the API returns success. Its result shows the below.
　　・Any exceptions never happen.
　　・The file has been created safely in transaction and
　　　it makes a record into the TxF log.

And between 4-1) and 4-2), I never take any operations (API calls) and
other application programs never run (as far as I could watch and manage).

I couldn't imagine the log does fill up between 4-1) and 4-2).
Does the system of TxF detect the filling-up of log implicitly to start aborting alive transactions ?

I guess that in the time of 4-2), the log fills up just in the operation
of 'CreateDirectoryTransacted'.

Does the idea of mine have any failure？

In Addition to these, I've found the other error code (out of WinError.h ) like the below.
＞//
＞// MessageId: ERROR_LOG_GROWTH_FAILED
＞//
＞// MessageText:
＞//
＞// An attempt to create space in the transactional resource manager's log failed. 
＞// The failure status has been recorded in the event log.
＞//
＞#define ERROR_LOG_GROWTH_FAILED          6833L

Why doesn't the API 'getLastError' return this error code after log's filling-up？

Answer 3

ERROR_LOG_GROWTH_FAILED is only returned when the log should have been able to grow but could not.  For example, consider a log whose maximum allowed size is 200 MB.  If the log is currently 100 MB in size when it fills up, but it cannot grow even though it should be able to get to 200 MB, then you will get this error.  In your case the maximum allowed size was 40 MB, so the log wasn't allowed to grow any more because it was as big as it was allowed to be.

I couldn't imagine the log does fill up between 4-1) and 4-2).

The create at 4-1 took the last bit of space in the log.  After the create at 4-1 succeeded, the log was full.  The create at 4-2 tried to write another log record, but there wasn't any space in the log for it.  TxF detected that the log was full and implicitly aborted the transaction.

---

Christian [MSFT]