Hello Andrew and Mark,
>>> > On Fri, 25 Dec 2015 15:16:15 +0800 Gang He <g...@suse.com> wrote: > >> When there are errors in the ocfs2 filesystem, >> they are usually accompanied by the inode number which caused the error. >> This inode number would be the input to fixing the file. >> One of these options could be considered: >> A file in the sys filesytem which would accept inode numbers. >> This could be used to communication back what has to be fixed or is fixed. >> You could write: >> $# echo "<inode>" > /sys/fs/ocfs2/devname/filecheck/check >> or >> $# echo "<inode>" > /sys/fs/ocfs2/devname/filecheck/fix >> >> Compare with second version, I re-design filecheck sysfs interfaces, there >> are three sysfs files(check, fix and set) under filecheck directory(see > above), >> sysfs will accept only one argument <inode>. Second, I adjust some code in >> ocfs2_filecheck_repair_inode_block() function according to upstream > feedback, >> we cannot just add VALID_FL flag back as a inode block fix, then we will not > >> fix this field corruption currently until having a complete solution. >> Compare with first version, I use strncasecmp instead of double strncmp >> functions. Second, update the source file contribution vendor. > > This feature should be documented, please. That means all pseudo-file > locations, all inputs, all outputs, expected behaviour etc etc. Enough > info so that our users can usefully and fully use this feature in the > minimum time. Documentation/filesystems/ocfs2.txt is the place for that. I ever sent out a document which describes this feature, I will modify that document sightly since sysfs interfaces have been adjusted, then send out to the list as a separated patch. Is it OK for you? Thanks Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/