h a l f b a k e r yInexact change.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
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?
[link]
|
| |
//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. |
|
| |
//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. |
|
| |
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. |
|
| |