Jamie Lokier wrote: > Marco Stornelli wrote: >> 2009/6/24 Jamie Lokier <jamie@xxxxxxxxxxxxx>: >>> Marco wrote: >>> If it loses power when doing atomic rename (to replace config files, >>> for example), it's likely that the whole /pramfs/configs/ directory >>> will be corrupt, because the rename is writing to the directory inode, >>> so you lose access to all names in that directory? >>> >>> That sounds like it can't be used for persistent configuration data. >> It's true from this point of view currently there is a lack for this >> and it needs a bit of effort to resolve this problem. >From this >> point of view I'd like to point out that I know that there was some >> aspects to study in a deeper way, so I'll need of more then one >> review :) but since this fs has been abandoned since 2004 and it >> hadn't ever reviewed, it was important to do a serious review with >> the kernel community to understand all the problems. > > That's reasonable. > > What do you think of my suggestion to double-buffer writes using a > single fixed position block, as explained elsewhere in this thread? > > It should give the power fail safety with very little code. I don't > know how much it would slwo down writing. That probably depends on > whether it's the checksum which is slow (which only needs to be done > once when double-buffering), or the writing. > > -- Jamie > Yeah it can be a choice. For this fs it's important to use "simple" but useful mechanism. What do you exactly mean with "fixed position block"? A fixed position in the fs? For example superblock+inodetable+in-use bitmap+blocks+"double-buffering block"? Using a temp block of the same size of blocks used, isn't it? I agree, but I think it needs more then 100 lines of code. Even with this simple schema it needs a mechanism with a timeout to do the "commit" of the temp block, it needs a mechanism to read the temp block instead of the "old" block or a mechanism to write-back the temp block. So it can be implemented but it needs a bit of effort. I think I'll implement it in the next release. Marco -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
