How to romove transaction data of TxF in the folder '$Extend' ？

Question

I know that in using Transactional NTFS(TxF) the transaction data as files has been created in the folder "$extend".

The construction of the files is the below.
　　C:\$Extend\$RmMetadata
　　　　　　　　　　\$Txf
　　　　　　　　　　\$TxfLog
　　　　　　　　　　　　\$TxfLogContainer00000…x+1
　　　　　　　　　　　　\$TxfLog.blf
　　　　　　　　　　　　\$Tops
　　　　　　　　　　　　\$Tops:$T
(Plese watch
"http://www.rc-flyer.com/Forensics/Class%205/Vista%20Forensics%20Overview.ppt". 
  It's Slide#38.)

But the folder '$extend' is one of special structure of NTFS.
And so I can't access the folder "$extend" in usual way.

When the transaction data of TxF has been crated in the folder "$extend" and it wastes the free space on a physical disk , What should I do ？
Can I remove the transaction data of TxF or make the backup copy of it ？
(Are there any tool programs or any APIs to remove or make backup copy ？)

Answer 1

The $Extend folder is special because system files required for NTFS's and Windows's proper operation live there.   Normally those files occupy less than 30 MB of space on the disk.  Since they are used by several Windows services (including Windows Update) you cannot remove them.

---

Christian [MSFT]

Answer 2

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

I have some more questions.
Could you give me some information about these？

1)　In the worst case, How much free space does
　　the transaction data of TxF in the folder '$extend' waste？
　　（You've described 'Normally those files occupy less than
　　　30 MB of space on the disk.'.
　　　I hope that you have the idea in the worst case too.)

2)　To make the limitation of usage of the transaction date
　　of TxF, Could I use 'fsutil.exe' ？

　　The below is usage of 'fsutil.exe'.

　　　C:\Users\Administrator>fsutil resource
　　　---- RESOURCE Commands Supported ----
　　　
　　　create          Create a Secondary Transactional Resource Manager
　　　info            Display information relating to a Transactional Resource Manager
　　　setautoreset    Set whether a default Transactional Resource Manager
                               will clean its transactional metadata on next mount
　　　setconsistent   Set a Transactional Resource Manager to prefer consistency over availability
　　　setavailable    Set a Transactional Resource Manager to prefer availability over consistency
　　　setlog          Change characteristics of a running Transactional Resource Manager
　　　start           Start a Transactional Resource Manager
　　　stop            Stop a Transactional Resource Manager
　　　
　　　C:\Users\Administrator>fsutil resource setlog
　　　---- SETLOG Commands Supported ----
　　　
　　　growth          Change the automatic growth settings
　　　maxextents      Change the maximum number of containers
　　　minextents      Change the minimum number of containers
　　　mode            Switch between undo only logging and full logging
　　　rename          Change the RM's Guid
　　　shrink          Change the automatic shrink settings
　　　size            Change the number of containers explicitly

Answer 3

 If you execute 'fsutil resource info' you can see information about the RM, including the default limits:

C:\Windows\system32>fsutil resource info \
RM Identifier:        28445053-DB5D-19DD-89DF-001E4FC34ED0
KTM Log Path for RM:  \Device\HarddiskVolume2\$Extend\$RmMetadata\$TxfLog\$TxfLog::KtmLog
Space used by TOPS:   1 Mb
TOPS free space:      100%
RM State:             Active
Running transactions: 0
One phase commits:    0
Two phase commits:    38
System initiated rollbacks: 0
Age of oldest transaction:  00:00:00
Logging Mode:         Simple
Number of containers: 2
Container size:       10 Mb
Total log capacity:   20 Mb
Total free log space: 10 Mb
Minimum containers:   2
Maximum containers:   20
Log growth increment: 2 container(s)
Auto shrink:          Not enabled

Here you can see that the default maximum is 20 log containers of 10 Mb each, or 200 Mb.  Be aware that 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 may impact the ability of, for example, Windows Update to properly apply updates to your system.

We recommend that you leave the defaults as they are.

---

Christian [MSFT]

Answer 4

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

I have some more questions again.

You've said.
＞We recommend that you leave the defaults as they are.

I get the idea as the below.
・Allmost all the transaction data of TxF has been created
  does not to waste the free area on the disk.
・We can use TxF/TxR without worrying about free area.

Do you intend to tell me the above？

But we could imagine the log fills up.
and the trouble we could imagine must be happend.

When the trouble like the above (the log fills up),What should I do？
I'd like to know the efficacious idea or informaion agaist the worst case.

Answer 5

Yes, TxF's log will not waste space on the disk.  It will occupy as much space as it needs to do its job.  By default the log will never be more than about 200 MB in size.

If the log fills up then TxF starts aborting transactions, starting with the longest-running, so as to reclaim space.  This is a behaviour common to most transaction-processing systems.  The only ways to get around that are to use shorter-running transactions or adjust the maximum allowable log size upward.

---

Christian [MSFT]

Answer 6

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

I have some more questions.
Could you give me some information about these？

＞The only ways to get around that are to use shorter-running transactions
＞or adjust the maximum allowable log size upward.

I've gotten that there are two ways like the following.
1)  To take apart the original transaction into the multiple and partial transactions
　　（that will be executed one by one).
2)  To make larger log space in order to allow longer trasactions run.

I've understand that I could take these ways.
But I've no idea about the below.
　　a)　How many transactions should I take apart into？
　　b)　How much is the size of the each fragmentary transactions to be took apart into？
　　c)　How much is the size of the log to be extended ？

By caliculating from the primitive information elements,
could I get the information like the above？
(and is there the fomula to caliculate？)
　　　　　　or
By trying to take the many and many cases to take apart into transactions
or to increase the log size,
Do I have to get the information step by step (little by little)？

If I took just the latter way and I was an application user
or an application developper with TxF,
I could imagine that I worry to take many and many cases.

Answer 7

It isn't possible to easily predict ahead of time how much space a transaction will occupy in the log.  Every operation you can do in a transaction generates a log record, and the log record sizes are different depending on the action.  Depending on the state of the filesystem extra records may be generated in response to an action, so you can't even always predict how many log records will be generated.  Besides that, there is other transactional activity in the system besides just your application program.  So you can't predict with any accuracy how much space you'll require.

For applications that perform thousands of operations in a single transaction you basically have to test with different log sizes to get an idea of how much space your particular application needs.  This is especially important if you are dealing with a small volume.  As I've mentioned before, the default size of the log is no more than 200 MB.  Once you're dealing with volume sizes below 2 GB, TxF sets up the default log size so that it will never occupy more than 10% of the volume.  So for example, on a 1 GB volume the log can't be more than 100 MB, for a 500 MB volume the log can't be more than 50 MB, etc.  Once the volume size is down to 10 MB TxF won't create the log at all and ceases to function.

---

Christian [MSFT]