| To: | Dave Chinner <david@xxxxxxxxxxxxx>, Brian Foster <bfoster@xxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH] xfsrestore: use utimensat() to provide atime/mtime with ns resolution |
| From: | Eric Sandeen <sandeen@xxxxxxxxxxx> |
| Date: | Thu, 04 Sep 2014 20:04:51 -0500 |
| Cc: | xfs@xxxxxxxxxxx |
| Delivered-to: | xfs@xxxxxxxxxxx |
| In-reply-to: | <20140905004501.GU20518@dastard> |
| References: | <1409848708-42666-1-git-send-email-bfoster@xxxxxxxxxx> <20140905004501.GU20518@dastard> |
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. In any case, there was a user who noticed & complained. Seems like a very reasonable thing to fix, to me. -Eric |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH] xfsrestore: use utimensat() to provide atime/mtime with ns resolution, Dave Chinner |
|---|---|
| Next by Date: | Re: [PATCH] xfsrestore: use utimensat() to provide atime/mtime with ns resolution, Dave Chinner |
| Previous by Thread: | Re: [PATCH] xfsrestore: use utimensat() to provide atime/mtime with ns resolution, Dave Chinner |
| Next by Thread: | Re: [PATCH] xfsrestore: use utimensat() to provide atime/mtime with ns resolution, Dave Chinner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |