On Sun, Jul 31, 2016 at 3:34 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > 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.... All the disclaimers above are very important for the administrator to know. But I believe that the answer to Ryan's original question is: Yes, there is a way of interacting at the file system level to facilitate a change of UID's on files rather than having to just chown recursively down the file system. I'm not sure how much faster it is going to be and whether anyone would want to invest time in writing this bulkchown tool, but it is definitely going to reduce Ryan's system downtime. Please correct me if I am wrong. Amir. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
