On Mon, Jul 25, 2016 at 11:25 PM, Vito Caputo <vito.caputo@xxxxxxxxxx> wrote: > I think this strategy is an improvement, but I'm a bit apprehensive > about how specific it is to this particular style of untar-like > directory metadata preservation failure in only providing stability to > directory inode numbers. > > Additionally it introduces a userspace-visible mount option, for > something which /feels/ like a stop-gap kludge to make some things > work better in the short-term. Maybe it's acceptable, since a more > general solution could be implemented later which ignores the added > mount option without conflict. Not sure that it's a kludge. AFAIR union-mounts copy up directory on lookup for simplicity of implementation. Overlayfs doesn't do that and it turns out to be not a big problem. But I don't have any input into the performance impact of doing this way or that. If it turns out to be unacceptable then we can think about some other solution (possibly something out-of-band, like aufs does). > As overlayfs usage increases in the "enterprise" via containers I > suspect we'll be seeing substantial support load from unsuspecting > users tripping over quirks like this and at some point there's a > threshold where user confidence is lost. Too true. > That is the lens I view > overlayfs problems like these through, hence I'd prefer a more general > solution with stable inode numbers making overlayfs behavior more > consistent with the filesystems backing it. Perhaps this needs to be the default then, turning it off to get the more space efficient but less conformant version. That risks being a regression for some, but hey, overlayfs is still somewhat experimental. > It's difficult for me to define what is "good enough" for overlayfs > correctness, and this situation seems like it might be one of those > epitomizing the saying "perfect is the enemy of good". If it breaks real apps, then it's not good. We need to fix it one way or the other. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
