Hi David, On Thu, Mar 10, 2022 at 07:53:07PM -0800, David Anderson via Linux-erofs wrote: > On Mon, Feb 28, 2022 at 10:14 PM Gao Xiang <[email protected]> > wrote: > > > > > > (Or maybe just "--preserve-mtime" if it's supposed to be used frequently in > > specific use cases...) > > Looking at this again - is a new flag needed? > > If -T is specified, the build will be reproducible. All timestamps > will be equal, and we'll never force an extended inode due to > mismatching timestamps. The patch has no effect in this case. > > If -T is *not* specified, inode mtime *could* be reproducible > (depending on how the user creates the files), but sbi.build_time > isn't. Any of these inodes that gets the compact layout will use the > unreproducible build time instead. So, switching to extended inodes > here strictly improves reproducibility and determinism.
Yeah, I know what's your main point here. Ok, that's fine we could change the current behavior. Yet I still think the current behavior may benefit some use cases (e.g. metadata size is sensible, we need to avoid extended inodes no matter per-filetimestamp is).. So instead, how about introducing --ignore-mtime instead for the current behavior, and change the default behavior into using extended inodes? > > That said, it is a change in behavior, so maybe that warrants a flag anyway. > > For what it's worth, in AOSP, "-T" is specified for production builds. > Non-production builds have "mtime" preserved for pushing incremental > changes. Thanks for the information! Thanks, Gao Xiang > > Best, > > -David
