<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Intrepid Blog &#187; fragmentedstream</title>
	<atom:link href="http://blog.affien.com/archives/tag/fragmentedstream/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.affien.com</link>
	<description>A few thoughts</description>
	<lastBuildDate>Mon, 01 Mar 2010 00:58:01 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Intrepid.IO.FragmentedStream</title>
		<link>http://blog.affien.com/archives/2004/12/14/intrepidiofragmentedstream/</link>
		<comments>http://blog.affien.com/archives/2004/12/14/intrepidiofragmentedstream/#comments</comments>
		<pubDate>Tue, 14 Dec 2004 18:30:13 +0000</pubDate>
		<dc:creator>Bas Westerbaan</dc:creator>
				<category><![CDATA[Computer Science]]></category>
		<category><![CDATA[.net]]></category>
		<category><![CDATA[fragmentedstream]]></category>

		<guid isPermaLink="false">http://blog.w-nz.com/archives/2004/12/14/intrepidiofragmentedstream/</guid>
		<description><![CDATA[While working on a design of a .pak files, which are nothing more then archives, I noticed most existing .pak files are just very simple. This for they put all files after eachother which makes it really hard to even just add a file, or delete one.
Therefor I started thinking about a way to make [...]]]></description>
			<content:encoded><![CDATA[<p>While working on a design of a .pak files, which are nothing more then archives, I noticed most existing .pak files are just very simple. This for they put all files after eachother which makes it really hard to even just add a file, or delete one.</p>
<p>Therefor I started thinking about a way to make an efficient archive file for read and write access.</p>
<p>There are basicly 2 ways to accomplish this:</p>
<ul>
<li>Clustering</li>
<li>Fragmenting</li>
</ul>
<p><strong>Fragmenting</strong>.<br />
The archive consists out of several files, and an index which is counted as a file. The start of every file is pointed to from the index by its offset. When a file is deleted, its record in the index is null-ed, which is lateron filled with a new entry and in the meantime ignored (for the only file that can start at position 0 is the index itself).</p>
<p>A file itself is fragmented, every fragment starts with 4 bytes marking the length of the fragment and after that again 4 bytes marking the offset of the next fragment this time. In case there is no next fragment present the next-cluster-offset is 0. The first fragment of every file contains after the 8 bytes marking the length and offset of the next fragment  some information about the file like the name.</p>
<p>For the index itself is a file, it also is fragmented and can grow, and shrink.</p>
<p>The 4 byte offset value could be default set to 8 bytes in case files are going to be  bigger than 2 Gig, and the oposite in case you are dealing with small files. Although this can decrease the size of files which are frequently edited it isn&#8217;t possible to increase or decrease to 8 or 2 bytes in runtime.</p>
<p><strong>Clustered</strong><br />
The clustered way is practicly the same as the fragmented way except for that every fragment is padded to a multiple of the cluster size. Therefore the &#8216;next fragment&#8217; value can now be a cluster number instead of an offset. This will both increase the speed of writing due to having always a buffer, also defragmenting will be faster. The files itself will also be able to retain a 2 byte next-cluster pointer longer. The only downside is that files will just be larger.</p>
<p><strong>FragmentedStream</strong><br />
The fragmented stream wraps these methods pretty efficiently at the moment.<br />
I am thinking to implement an inteligent algorithm which checks which streams are often used which are then placed at the end of the file with a buffer. This also could be applied for files which are marked to be expanding.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.affien.com/archives/2004/12/14/intrepidiofragmentedstream/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
