On 25/10/2019 03:36, Dave Chinner wrote: > On Fri, Oct 25, 2019 at 02:29:04AM +0300, Boaz Harrosh wrote: <> >> Perhaps we always go by the directory. And then do an mv dir_DAX/foo dir_NODAX/foo > > The inode is instatiated before the rename is run, so it's set up > with it's old dir config, not the new one. So this ends up with the > same problem of haivng to change the S_DAX flag and aops vector > dynamically on rename. Same problem, not a solution. > Yes Admin needs a inode-drop_caches after the mv if she/he wants an effective change. >> to have an effective change. In hard links the first one at iget time before populating >> the inode cache takes affect. > > If something like a find or backup program brings the inode into > cache, the app may not even get the behaviour it wants, and it can't > change it until the inode is evicted from cache, which may be never. inode-drop-caches. (echo 2 > /proc/sys/vm/drop_caches) > Nobody wants implicit/random/uncontrollable/unchangeable behaviour > like this. > You mean in the case of hard links between different mode directories? I agree it is not so good. I do not like it too. <> > We went over all this ground when we disabled the flag in the first > place. We disabled the flag because we couldn't come up with a sane > way to flip the ops vector short of tracking the number of aops > calls in progress at any given time. i.e. reference counting the > aops structure, but that's hard to do with a const ops structure, > and so it got disabled rather than allowing users to crash > kernels.... > Do you mean dropping this patchset all together? I missed that. Current patchset with the i_size == 0 thing is really bad I think. Its the same has dropping the direct change all together and only supporting inheritance from parent. [Which again for me is really not interesting] > Cheers, > -Dave. Lets sleep on it. Please remind me if xfs supports clone + DAX Thanks Dave Boaz
