Proposed is [hopefully] a more efficient way to store information on a hard drive. Current systems (if I understand correctly) are limited to the number of blocks of information able to be addressed--set by the number of bits used to address them. To overcome this limitation, the size of the blocks is increased until the drive can be fully addressed. Small files take a minimum of the block size with this method. Proposed is a floating-point system of addressing and of file sizing. The smallest files would all be addressed to the exact byte and would not waste any space on the drive (save for the overhead on the file table). Large files would have empty chunks after them to sufficiently guarantee that no smaller files are lost in the roundoff error.

This idea is perhaps only an eighth baked, but is it a good starting point?
-- kevinthenerd, Aug 10 2010

//The smallest files would all be addressed to the exact byte and would not waste any space on the drive// Thing is, 'floating point' is an approximation of the representation of a number - a 32-bit floating point number stores the same amount of information* - as a 32 bit integer - so you're not gaining anything there.

*the amounts being referenced might have different ranges, but *information* is a measure of precision and what you gain in range with the floating point, you lose in precision - so the "smallest files would" NOT "be addressed to the exact byte" - which is what you need for a disk- access index.
-- zen_tom, Aug 10 2010


Use paper tape.
-- nineteenthly, Aug 10 2010


//Use paper tape.//
IIRC, paper tape character pitch was/is of the order of 1/10" (2.54mm).
A terabyte paper tape would be 1.6 million miles (2.6 million km) long.
-- coprocephalous, Aug 11 2010


FP includes a sign-bit so it would actually take up *more* room.

You *might* be able to do something weird with different int sizes but then the file-manager would have to know in advance how to write the file, and the calling program would need to know in advance, how the file-manager wrote the file... seriously yuck.

*But* since large files are almost exclusively a/v media and archive, putting them on their own partition, with a mammoth cluster-size will work just fine.

Alternatively (my own idea for a huge-files partition) is to treat each physical track as a "sector". The File Manager would then manage files to/from the programs in smaller static-length chunks, while read/writing the disk in entire (dynamic-length) tracks. It would be the most efficient I/O-wise.

HD's typically have a real "sector" size of 512 bytes, so you're not getting any smaller than that.
-- FlyingToaster, Aug 11 2010



random, halfbakery