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. > > If a directory is marked as bad, or a file-inode in it is marked bad, > can you even rmdir it to clean up and start again? > You can start again always. You can remount the fs with the init option and then you'll have a new fs. Marco -- 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
