Hi Ryusuke, On 2014-01-19 17:49, Ryusuke Konishi wrote: > Could you consider adding NILFS_IOCTL_SET_SUINFO instead of extending > v_flags of NILFS_IOCTL_CLEAN_SEGMENTS ? Yes sure. I actually considered that writing the patch, but then shyed away from adding a new ioctl. > It is hacky to extend NILFS_IOCTL_CLEAN_SEGMENTS like this, and, > unfortunately, argv[]->v_flags of NILFS_IOCTL_CLEAN_SEGMENTS is not > zero-filled in the current library implementation. This is our > mistake (so I will fix it soon), but we cannot use these flags for > some time. Otherwise, existing cleanerds will go wrong when this is > merged into kernel. Ah yes I didn't think of that. > Presence of ioctls can be tested with ENOTTY error, so libnilfs > can know whether nilfs in underlying kernel has NILFS_IOCTL_SET_SUINFO > ioctl or not, and we can extend the library keeping compatibility > by using this nature. > > A good example of code updating metadata file is > nilfs_ioctl_change_cpmode() even though NILFS_IOCTL_SET_SUINFO will > need nilfs_ioctl_wrap_copy(). It would be helpful for you. > > Additional comments are as follows: > > - For NILFS_IOCTL_SET_SUINFO, v_flags should be used to define which > fields (lastmod, nblocks, flags) are modified. These flags should > be defined with bit masks. Thank you for your comments. I will try and implement it and come back with a new version of my patch. Best regards, Andreas Rohner -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html