On Thu, Sep 04, 2014 at 08:04:51PM -0500, Eric Sandeen wrote: > On 9/4/14, 7:45 PM, Dave Chinner wrote: > >On Thu, Sep 04, 2014 at 12:38:28PM -0400, Brian Foster wrote: > >>xfsdump encodes and stores the full atime and mtime for each file with > >>nanosecond resolution. xfsrestore uses utime() to set the times of each > >>file that is restored. The latter supports resolution of 1 second, thus > >>sub-second timestamp data is lost on restore. > > > >That doesn't seem like a big deal. What sort of problems does this > >actually cause? > > > >FYI, many linux filesystems only have second resolution timestamps > >and hence applications can't rely on sub-second timestamp resolution > >to actually mean anything useful.... > > But why not restore the same resolution as is actually stored in the dump? > Throwing it away seems odd, and restoring it looks easy enough. Comes from a time when we couldn't restore what was in the dump. :/ > In any case, there was a user who noticed & complained. Seems like a > very reasonable thing to fix, to me. Sure, but we don't make changes with the justification "just because". xfsrestore has had this behaviour since dump/restore was first introduced, so first we need to understand what the actual problem is. Was the user complaining because they noticed they were "different" in passing, or was it noticed because the difference is the root cause of some other problem? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
