On 6/9/2011 12:36, Patrick Elliott wrote:
> 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.

This is FAT. The directory data only points to the first granule. You have 
to go back to the file allocation table for anything else. Which is exactly 
why it's slow when you have lots of small files.

> 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.

The reliability comes from the fact that you're basically keeping both 
copies around until you finish, and marking it as "finished" is atomic.

So you write a file. You have to update the directory, the allocation map 
for what blocks the file occupied, and you have to clear the bits out of the 
bitmap that says those blocks are free. Those three items might be in three 
different places on the disk.  What happens if you record where the file is 
stored, then mark those as used in the bitmap, and someone pulls out the 
disk between those two steps?

With a journal, you'd record those two operations in the journal, then you'd 
perform those two operations, then you'd record in the journal that you 
completed them. Anything missing that last step gets rolled back, just like 
in any other database system.

> You still need to have the shit you did *on* the disk, so
> you can replay it.

Right. But you don't overwrite the old version until *all* parts of the new 
version are recorded. Just like in a database transaction, you don't 
overwrite the balance of the account you're taking money out of before 
you're recorded that you want to put money into the other account.

You basically wind up recording your intention, then executing your 
intention, then recording that you've finished executing your intention. The 
journal isn't really for efficiency as much as it is for reliability.

Of course, in this particular case, it serves as both, specifically 
*because* you wind up being able to stage storing a bunch of files, *then* 
doing a bunch of updates to areas of the disk that are far apart.

 > "write once, update the table saying where the data is, and you are
> done", seems to me to make a lot of damn sense,

That's how a lot of systems work, except you still eventually need to get 
rid of the old stuff.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message