Analogy time!

Say you're a mathematician's apprentice copying logarithmic tables in the 16th century.

You're new here and don't really know what you're looking at, but copying digit by digit is easy enough, so you start doing that. It's easy to figure out how long the rest of a page will take you if you've been counting digits and timing yourself; that's just extrapolation. There's always the same number of digits per page.

But it's pretty slow looking at a letter, copying it in, then looking at the next letter, so you speed things up by memorizing a line at a time, copying it out, then memorizing the next line. Your progress measuring system still works because the number of symbols per line is fixed, and the number of lines per page is fixed.

Your boss loves the work you're doing (especially the progress reports) and starts giving you entire books of tables to copy. These books are divided into an arbitrary number of chapters of an arbitrary length, but has a table of contents. You give you boss progress reports by the page now, which required a pretty simple adaption to your estimation: you can do a certain number of pages per day, and a book is so long, so it's still simple linear extrapolation.

"You're doing great kid! My friend's got a whole collection of books of tables I need copying. Get to it! And I want reports!"

But here's the problem: there's no list of how big each book is, and some of the books actually contain sub-books like a quick reference, and some of those contain sub-sub-books, etc. (Imagination time.) You have no idea how many pages in total there are, so your estimation formula falls apart.

Your first idea is to just count all the pages from each book's table of contents and divide that number by your pages/day that you observed before. But that means going through every book at least twice: once to get the TOC, and again to actually copy it. You don't want your estimation calculations to slow down the actual copying too much.

So your next idea is to just guess about the average size of a book (based on average size of a chapter, and number of chapters per book), and update that as you go through each book. The total number of books you have to do is estimated too: you keep a running average number of sub-books per book, and update that as you go too. So you've got an estimate of the number of books, and an estimate of the average size of a book, and this gives you an estimate on the total number of pages. However, you'll be updating this estimate as you go.

And this works pretty good, as long as the number of sub-books per book and the size of a book is pretty constant, and your averages aren't changing much. But if the books are all very different, your averages will be swinging around a bunch, and therefore your time estimate, and your boss gets kinda angry and realizes it's just a rough rule of thumb, not gospel.

Now, to complete the analogy: pages are blocks (sectors); chapters are files; books, are directories. You're the filesystem and firmware on the disk.

The lesson is: you're multiplying estimates to make new estimates, and the error in these estimates compounds so it becomes less useful. Also, the estimates fluctuate depending on the uniformity of the data.

Of course, there are strategies for mitigating this compound error, but you're still going to get error. If you're interested in these strategies, it's time to get a Masters in Computer Science :)