On Mon, Mar 27, 2017 at 12:23 PM, Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: > On Tue, Mar 21, 2017 at 04:14:49PM -0400, Amir Goldstein wrote: >> On Thu, Dec 22, 2016 at 12:25 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >> > If caller provided the target dtype to use and indicated that with >> > rename() flag RENAME_VFS_DTYPE, use RENAME_DT_MODE(flags) instead >> > of inode->i_mode to determine the value of dtype to store in the >> > directory entry. >> > >> > Adding this functionality to official xfs code will require to add >> > a new feature flag to xfs directry naming on-disk format. >> > >> > Without that new feature flag, xfs_repair will report that custom >> > dtype as a warning and set it back to the dtype value according to mode. >> > >> > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> >> >> Ted/Darrick, >> >> That's the XFS POC implementation of the proposed API. >> I am not re-posting the entire series that uses this for optimizing >> overlay readdir. >> It can be found here: >> https://www.spinics.net/lists/linux-unionfs/msg01401.html > > Welll.... at a bare minimum you ought to post this to the XFS list if > you're serious about trying to merge this. I suspect there will be I guess I did not send it to xfs list because it was just an "internal POC" for overlayfs optimization and I picked xfs as a convenient target as it is the only fs that already had FT_WHT type defined. I should have posted to fsdevel though - I though I did.. > pushback against allowing in-kernel(?) clients to set ftype arbitrarily, > since the details of that field weren't designed to be directly > accessible outside XFS. Well, I was going to propose an API to set private ftype flags and it is up to fs to implement this (by allowing the RENAME_VFS_DTYPE flag), but it was easier to modify xfs just for setting FT_WHT/FT_UNKNOWN and it was enough for my POC. > > Next, if you're only setting FT_WHT or FT_UNKNOWN (both of which at > least already exist as code points) then you'll have to supply a fix to > xfs_repair. If you want to do more than that (i.e. use the unused ftype > bits) you'd have to implement kernel and userland patches to add an > incompat feature flag so that unaware kernels don't trip over the extra I know. even wrote this in commit message :-) > bits. You'll also have to send updates to the disk format documentation > to reflect the changes you're making, and some test cases to ensure that > it all actually works. > > While I think I understand what you're trying to accomplish, you'll have > to argue for it on the XFS list. :) > The way this played out was: - I did the POC a while ago - I proposed to discuss it as part of 'container aware fs' slot with James - I discussed this with Miklos he convinced me this was an over optimization for overlayfs (for the average use case) - Steve French brought up the need to mark directory entries (for sparse files) without having to stat(x) them, so I mentioned this patch could be relevant I can't say that I fully understand the network file system needs in that regard, so I can't say if this approach is any help - just wanted to put it out there. That said, if there is interest, I can certainly try to push this forward, including tests on-disk format doc etc. Cheers, Amir.
