> > > I think upper files data can "evaporate" even as the overlay is still mounted. > > > > I think assumption of volatile containers was that data will remain > > valid as long as machine does not crash/shutdown. We missed the case > > of possibility of writeback errors during those discussions. > > > > And if data can evaporate without anyway to know that somehthing > > is gone wrong, I don't know how that's useful for applications. > > > > Also, first we need to fix the case of writeback error handling > > for volatile containers while it is mounted before one tries to fix it > > for writeback error detection during remount, IMHO. > > > > Thanks > > Vivek > > > > I feel like this is an infamous Linux problem, and lots[1][2][3][4] has been said > on the topic, and there's not really a general purpose solution to it. I think that > most filesystems offer a choice of "continue" or "fail-stop" (readonly), and if > the upperdir lives on that filesystem, we will get the feedback from it. > > I can respin my patch with just the "boot id" and superblock ID check if folks > are fine with that, and we can figure out how to resolve the writeback issues > later. > On the contrary. Your code for error check is very valuable and more important than the remount feature. If you change ovl_should_sync() to check for error since mount and return error in that case, which all callers will check, then I think you fix the evaporating files issue and that needs to come first with stable kernel backport IMO. Thanks, Amir.
