On Wed, Dec 29, 2010 at 4:30 PM, Christian Stroetmann <stroetmann@xxxxxxxxxxxxx> wrote: >> True, I don't understand why people say it will cause a performance >> hit but then don't want to tell why. > > We are talking about atomicity. And it is a simple fact in the field of > information processing/informatics/computer science that if someone wants to > give/have the guarantee of atomicity, then she/he has to do several > additional steps often by using an additional data structure. In the end Additional steps compared to what? The temp file, fsync, rename case? > this all costs more time and/or space than doing it without atomicity. At Of course. But this should not affect the non-atomic usage. > this point there is no discussion anymore, because this is fully discussed > to the maximum in subjects like Efficient Algorithms, Special Problem Fields > of Operating System Design and Fundamentals of DBMS Design (eg. AtomicityCID > principle). > And such fundamental points are not (needed to be) discussed here. > > Furthermore, due to the competence it is possible for FS gurus like Ted to > estimate that the additional steps have to be done by several functions of > an FS, which implies performance loss. And because elementary FS functions > are involved the performance loss could be and in the past have been > significant, though in nearly all cases I have seen the reason was a very > bad implementation. The only exception so far is the Reiser4 FS: All of its > file operations are atomic, but still to a little cost of performance in the > most cases and the need of a repacker in some few cases which show a > significant loss of performance. So making all ops atomic can be done at a little performance hit, but implementing one specific op costs a huge performance hit? That doesn't make sense and seems to indicate those that say otherwise aren't right. > And the advice to use a well-known DBMS is simply based on the knowledge > that it has all the needed functionality already implemented in a highly > performant way, and on the knowledge that such a solution is used oftenly > for comparable use cases due to the cost vs. benefit ratio. > To take a look at the Reiser4 FS could also help. I don't think storing all my conf files, executables, libraries etc in a DBMS is a good idea... Olaf -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
