Any better way to interact with xfs?

[Dave Chinner]

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 at fromorbit.com> 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 at fromorbit.com