Re: Toll Booth and junk (was Re(fcc): TI-H: Radio/In...)
[Prev][Next][Index][Thread]
Re: Toll Booth and junk (was Re(fcc): TI-H: Radio/In...)
>From: "Jon Olson" <morph@jmss.com>
>no...a bitmap would be quite fast actually, it's what some operating
systems
>(QNX for example) use for free block checking.
I'm not sure I know what you mean by using a bitmap.
I suggested using a table of fixed length entrys that
describes the data on the remainging portion of the
drive (which consists of variable length contigious blocks).
>I do agree that periodic
>defragging is good, but having it so that you can't send over any more
mp3s
>if you don't have a free block large enough to hold them? that's what i
>considder silly.
If the system supports free space defragmentation this
would't be a problem at all.
>Using a bitmap, you would be able to quickly find the free
>space needed to store the mp3, and have a few bytes in the header, as
well
>as a flag bit saying "file fragment, more stored here", and then on the
last
>fragment have a "final fragment." It's fast, and wouldn't require very
much
>codespace to implement.
Its also alot more complex then storing the data in
contigious blocks and just including a free space
defrag.
In the system I outlined the player can very simply
locate a large enough block and drop the data directly
into it, no chaining involved. Since the songs will
(for the most part) be of similar lengths, dropping
the new songs into holes left by deleted songs should
keep free space fragments reasonably small.
It is possable that there could be no contigious blocks
of sufficent length to store a song, but if you start
doing chaining storage you will run into the need for
a much more complicated defrag utility which can handle
the chains. This type of defrag is much more complex
then simple free space defragmentation.
DK
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Follow-Ups: