On Wed, Nov 27, 2019 at 06:19:29AM -0800, Christoph Hellwig wrote: > Can we all take a little step back and think about the implications > of the original patch from Alex? Because I think there is very little. > And updated sunit/swidth is just a little performance optimization, > and anyone who really cares about changing that after the fact can > trivially add those to fstab. > > So I think something like his original patch plus a message during > mount that the new values are not persisted should be perfectly fine. > I agree, FWIW. I've no issues with the original patch provided we fix up the xfs_info behavior. I think the "historical behavior" argument is reasonable, but at the same time how many people rely on the historical behavior of updating the superblock? It's not like this changes the mount api or anything. A user would just have to continue using the same mount options to persist behavior. Eric pointed out offline that we do refer to using the mount options to "reset" su/sw in at least one place (repair?), but I don't see why we couldn't rephrase that and/or provide a repair/admin script that updates on-disk values. Still just my .02. :) Brian > We can still make xfs_repair smarter about guessing the root inode > of course. >
