Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Status report
From: Linus Nielsen Feltzing (linus_at_haxx.se)
Date: 2002-05-08


Matt.OReilly_at_wachovia.com wrote:
> Is it really that complicated? I may not understand the problem, but
> here's a thought.
>
> I haven't looked into FAT32 at all, but I thought that in FAT16 the end of
> each cluster there was a reserved space populated with the address of the
> next cluster. Putting them back in order was one of the features of
> vopt/norton defrag/etc. because when the files were contiguous after the
> optimization, there was a whole lot less overhead to find each piece.

The FAT file system has a separate table for the cluster chaining, the
FAT (File Allocation Table). So the next-cluster information is not in
the cluster itself. Otherwise you are correct.

> So it would seem to me, following this (perhaps flawed) logic, that we
> could get by by only moving the first portion of the cluster of the new
> file to a new location and linking back to the second cluster through the
> FAT32 addressing. (Hmmm, maybe that's how fragmentation got started...)
> We would lose a lot of space depending on how often this was done between
> defrags (which I think would have to be run fairly often if this was used a
> lot), but I *think* it would mean that we would only have to copy the
> contents of one cluster to a new cluster, and not rewrite the whole file.

Your logic is somewhat flawed. The first part of the file is easy, as
pointed out. The second part is not that easy, since FAT only handles
whole clusters, except for the last cluster, which of course can hold
less information (that is referred to as "slack").

So if we split a file in the middle of a cluster, the second file would
begin with a partial cluster, and FAT can't handle that (except for the
last one).

/Linus



Page was last modified "Jan 10 2012" The Rockbox Crew
aaa