On Thu, Jan 12, 2017 at 12:03:28PM -0500, Theodore Ts'o wrote: > On Thu, Jan 12, 2017 at 04:00:16PM +0800, zhangyi (F) wrote: > > > > At the same time, I think other file systems may have the same problem, do > > you think we should put these detections on the VFS layer? Thus other file > > systems no need to do the same things, but the disadvantage is that we can > > not call ext4_error to report ext4 inconsistency. > > There are file systems which don't have inodes per-se where the > i_nlinks could be a something which is simulated by the file system. > So it's not *necessarily* an on-disk inconsistency. > > We'll have to see if Al and other file system developers are > agreeable, but one thing that we could do is to do the detection in > the VFS layer (which it is actually easier to do), and if they find an > issue, they can just pass a report via a callback function found in > the struct_operations structure. If there isn't such a function > defined, or the function returns 0, the VFS could just do nothing; if > it returns an error code, then that would get reflected back up to > userspace, plus whatever other action the file system sees fit to do. Detection of what? Zero ->i_nlink on inode of dentry that passes e.g. may_delete()? -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
