On Thu, 2012-08-02 at 10:03 -0700, Tim Bird wrote: > > So can I interpret this the following way. Not only fastmap give no > > guarantees that it exists after an unclean reboot, it does not even give > > guarantees that it exists after a clean reboot. > > > > Unless I am confused, the fastmap design is over-simplified. > > Fastmap is an optimization. Maybe I'm missing something, but > I'm not sure why, if the optimization stopped working, you > would want to reduce the functionality of the file system.
Fastmap gives huge improvement in attach time. So big that it becomes not just optimization, but a selling feature. Or very important optimization. If you design a system which requires 1s startup time, you probably want to always guarantee 1s startup time. E.g., if we are talking about a car system. You probably may get away with the fact that in case of power cut your system starts up 10 seconds at the first boot (no fastmap). But you probably would be disappointed if I say that even if you do _not_ have power cuts, your system may still startup 10 seconds, although most of the times it will take 1s. Does this description help to accept my POW that while we cannot simplify fastmap and give no improvement for the power cut cases, it is quite important to guarantee that in normal cases fastmap is always there, and UBI will always be fast. If I buy a car which runs 200Km/h on the asphalt, I am OK if it cannot do this on the cross-country trails, but I am not OK if it sometimes cannot do 200Km/h even on the asphalt, when the moon is blue. -- Best Regards, Artem Bityutskiy
signature.asc
Description: This is a digitally signed message part
