On Friday 12 February 2016 01:21:59 Deepa Dinamani wrote: > Introduction > > This is a follow on to the series: https://lkml.org/lkml/2016/1/7/20 [1]. > This is aimed at reaching a consensus on how to transition the vfs > timestamps to use 64 bit time. This demonstrates three ways (2a, 2b and > 2c) of solving this problem. Each of the proposals has its own cover > letter that explains the individual approach. Proposals 2b and 2c also > outline variant approaches which are similar to the respective proposals. > This drives the proposal count to 5. All the changes have been discussed > with Arnd Bergmann, who posted the original series: > https://lkml.org/lkml/2014/5/30/669 [2] > > The series has been simplified to include only the 64 bit timestamp > changes as per Dave Chinner’s suggestion. > > Motivation > > The problem is how to change the vfs inode timestamps to use 64 bit > times to overcome the 2038 problem. > > Below table [3] gives an overview of the extent/ type of changes > needed of changes needed. > The series is aimed at obtaining small manageable patches for all > the cases in [3]. > Hi Deepa, Thanks a lot for posting this updated series, very nice work! Regarding the three versions, I think all of them are doable doable, and they all have their upsides and downsides but no showstoppers. Let me summarize what I see in the patches: 2a is the smallest set of changes in number of lines, as you indicated in the previous discussion (I was skeptical here initially, but you were right). The main downside is that each patch has to carefully consider what happens at the point when the type gets flipped, so that printk format strings are correct and assignments to local variables don't truncate the range. It also requires changing the types again after the VFS change, but that is something we can automate using coccinelle. 2b has the main advantage of not changing behavior with the flip, so we can convert all file systems to use vfs_time relatively easily and then later make them actually use 64-bit timestamps with a patch that each file system developer can do for themselves. One downside is that it leads to rather ugly code as discussed before, examples are in "[RFC v2b 5/5] fs: xfs: change inode times to use vfs_time data type" and "[RFC v2b 3/5] fs: btrfs: Use vfs_time accessors". 2c gets us the furthest along the way for the conversion, close to where we want to end up in the long run, so we could do that to file systems one by one. The behavior change is immediate, so there are fewer possible surprises than with 2a, but it also means the most upfront work. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
