Marco Stornelli wrote: > 2009/6/24 Jamie Lokier <jamie@xxxxxxxxxxxxx>: > > Marco wrote: > >> > Second question: what happens if the system crashing _during_ a write > >> > to a file. Does it mean that file will fail it's checksum when it's > >> > read at the next boot? > >> > > >> > Maybe files aren't so important. What about when you write a file, > >> > and then rename it over an existing file to replace it. (E.g. a > >> > config file), and the system crashes _during_ the rename? At the next > >> > boot, is it guaranteed to see either the old or the new file, or can > >> > the directory be corrupt / fail it's checksum? > >> > >> First of all I have to explain better the current policy: the checksum > >> works at inode and superblock level and currently there isn't a recovery > >> function as the journaling. About the superblock it's easy to use a > >> redundant policy to be more robust. > > > > To be honest, superblock robustness is less of a concern. The real > > concern is losing file or directory contents, so it can't be used to > > store persistent configuration data, only debugging logs. > > > >> About the inode, at the moment when the checksum doesn't match the > >> inode it's marked as bad calling the function make_bad_inode(). > > > > Let's see if I understand right. > > > > If it lose power when writing to a file, after boot the file is likely > > to be marked bad and so return -EIO instead of any file contents? > > Depends on the checksum. If you lose power before the checksum update > of the inode > you'll have a bad inode and then an -EIO at the next access. > > > > > 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 -- 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
