On Sat, Jul 30, 2016 at 05:26:03PM +0300, Amir Goldstein wrote: > On Fri, Jul 29, 2016 at 5:25 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > On Thu, Jul 28, 2016 at 09:48:07AM +0300, Amir Goldstein wrote: > >> Hi Ryan, > >> > >> You could use the XFS_IOC_FSINUMBERS/XFS_IOC_FSBULKSTAT API to iterate > >> over all inodes in the fs. > > > > That's a read-only API - you can't use it to change the inodes > > on disk. > > > >> not having to readdir and recourse the directory tree should safe you > >> some time (much less i/o). > >> Also, the interface can be used to make your conversion work parallel > >> by working on different inode ranges. > > > > It cannot be used to make coherent, atomic changes to the inode > > state. > > > > I'm curios: In theory, one can construct a file_handle from bulkstat > info. correct? > and one could use that handle to open_by_handle_at() and fchown(). right? > I realize that both APIs were not intended for this use case, but I wonder: > 1. can it be done? Yes. See xfs_fsr. > 2. what are the possible consequences? You can modify the data any file in the filesystem without leaving a trace. Files opened this way do not get their c/mtime changed when modified by syscalls, and only on CRC enabled filesystem is it possible to tell if the inode metadata was changed this way. You still can't tell if file data was changed. > 3. what do you mean by "coherent, atomic changes to the inode state"? > does it not play well with the dentry/inode cache? The inode can change between bulkstat time (i.e. the info the kernel returned about the inode) and the time you have an open fd and make the change you want to make. It could have been renamed, it could have been truncated, it's permissions could have been changed, etc. None of these sorts of checks are run when opening by filehandle. i.e. it's all the same coherency issues that we have with multiple NFS clients modifying the same file concurrently. They don't know what each other are doing, and so modifications are going to get lost or be overwritten incorrectly.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
