On Tue, Aug 20, 2019 at 06:51:01AM -0400, Brian Foster wrote: > On Tue, Aug 20, 2019 at 04:53:22PM +0800, kaixuxia wrote: > FWIW if we do take that approach, then IMO it's worth reconsidering the > 1-2 liner I originally proposed to fix the locking. It's slightly hacky, > but really all three options are hacky in slightly different ways. The > flipside is it's trivial to implement, review and backport and now would > be removed shortly thereafter when we replace the on-disk whiteout with > the in-core fake whiteout thing. Just my .02 though.. We've got to keep the existing whiteout method around for, essentially, forever, because we have to support kernels that don't do in-memory translations of DT_WHT to a magic chardev inode and vice versa (i.e. via mknod). IOWs, we'll need a feature bit to indicate that we actually have DT_WHT based whiteouts on disk. So we may as well fix this properly now by restructuring the code as we will still have to maintain this functionality for a long time to come. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
