On one of the projects I was seeing recurring behavior where “D:\FAST Search\data\ftStorage\sequences” folder quickly fills up with files like storage_6a.data , storage_cd.meta thus causing the drive to run out of space. That location is used to store index (“fixml”) information used for fault tolerance (ft) in a backup indexing row. We have deleted these files at some point since there was an environment health issue as well, hoping that fixing the environment issue was to blame for causing this folder to fill up, but it came back again and quickly filled up the drive. In searching for the cause of the problem here is what was found.
1. It’s likely this is happening if one or more servers are configured as a “secondary” indexing row. See this example from a FS4SP deployment.xml file:
<searchcluster>
<row id="0" index="primary" search="true" />
<row id="1" index="secondary" search="true" />
</searchcluster>
The options are to disable the secondary/backup indexer(s), or add more disk space to the backup row.
If the data was deleted in this folder, it’s likely the backup index data is out of sync, and will need to be resynchronized with this procedure:
“Synchronize the primary and the backup indexer servers (FAST Search Server 2010 for SharePoint)” - http://technet.microsoft.com/en-us/library/gg482028.aspx
2. In our case the box that had this issue was not configured as a secondary row, but was a primary row.
The deployment.xml has not used row 0 as the primary row (which is required, ref http://technet.microsoft.com/en-us/library/ff354931.aspx#element_searchcluster)
This caused the ftstorage files to neither be placed on the intended server, nor rotated and thus eating up the disk space.
Here is an example of the deployment
<host name="FAST01 ">
<admin/>
<crawler role="single"/>
<webanalyzer lookup-db="true" link-processing="true" max-targets="2" server="true"/> <document-processor processes="4"/> <content-distributor id="0"/> <indexing-dispatcher/>
<query/> <searchengine column="0" row="0"/> </host>
<host name="FAST02 ">
<document-processor processes="4"/>
<content-distributor id="1"/> <indexing-dispatcher/>
<query/>
<searchengine column="0" row="1"/>
</host>
<searchcluster>
<row id="1" search="true" index="primary"/> <row id="0" search="true" index="secondary"/>
</searchcluster>
Once the IDs were reconfigured and then I ran Set-FASTSearchConfiguration on the admin box as well as the non-admin. The issue went away
Enjoy
Nathan Treloar, is VP of Technology for Strategic Alliances at RAMP where he is responsible for expanding RAMP’s industry leading Content Optimization solutions into new markets. Prior to RAMP, Nate was the Principal Search Technology Evangelist in the Microsoft Enterprise Search Group and held responsibility for the group’s technology innovation and evangelism programs. 
