POV-Ray : Newsgroups : povray.off-topic : A retro moment : Re: A retro moment Server Time
30 Jul 2024 00:19:48 EDT (-0400)
  Re: A retro moment  
From: Patrick Elliott
Date: 9 Jun 2011 15:36:30
Message: <4df120be@news.povray.org>
On 6/7/2011 6:45 AM, Darren New wrote:
> On 6/7/2011 3:58, Invisible wrote:
>> Quite why Windows can't just write the final listing to the directory
>> block
>> and then write all the file data blocks sequentially is beyond me, but
>> anyway...
>
> Read up on how FAT works. It's not seeking back to write the directory
> listing. It's seeking back to read/write the FAT table.
>
> Given modern memory sizes, it ought to be able to cache the FAT table,
> especially given that one might very reasonably be having only one
> process with files on the disk open to start with. But I suspect not a
> whole lot of time was put into optimizing that.
>
> Blame UNIX. The CP/M operators were much faster. :-)
>
First off, for storage media, you don't want to do it that way in the 
bloody first place. You want to make sure the data is actually there 
*first*, so that when you point the file table to it, its not pointing 
at empty disk space. But, to do that, you have to go back to where the 
directory data is located, and update it to point at the now *actually 
there* data.

Personally, I never *quite* understood how you get more reliability, 
with something like storing what you are doing, so you can replay it, if 
the disk gets unmounted. You still need to have the shit you did *on* 
the disk, so you can replay it. Which means that the only thing you 
might be saving is some seek time, if you have your session data stored 
at the start of the disk, and the final write/replay goes to a bunch of 
different places. Its basically writing to a swap file, then using that 
to generate the data, if the power goes out. But, you have to write the 
data, then read it, then write it again, to finalize the changes. Sure 
it makes sense to someone, and works, but, unless you are storing that 
shit of flash ram, or something, then writing it out to slower media, 
you are doubling the amount of stuff you are doing, probably wearing out 
the disk faster, since you are rewriting your transaction record to the 
same swap area over and over, and so on. The whole, "write once, update 
the table saying where the data is, and you are done", seems to me to 
make a lot of damn sense, if you want to be *sure* it gets written. All 
the rest is done for speed, not reliability. So.. Which is more 
important to you, actually having the data, when you need it, or being 
able to load/change it very very fast? You don't get to have both.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.