From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Brian Foster <bfoster@redhat.com>, xfs@oss.sgi.com
Subject: Re: [PATCH] xfsrestore: use utimensat() to provide atime/mtime with ns resolution
Date: Fri, 5 Sep 2014 11:24:04 +1000 [thread overview]
Message-ID: <20140905012404.GV20518@dastard> (raw)
In-Reply-To: <54090C33.2060102@sandeen.net>
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@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-09-05 1:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-04 16:38 [PATCH] xfsrestore: use utimensat() to provide atime/mtime with ns resolution Brian Foster
2014-09-04 19:47 ` Eric Sandeen
2014-09-04 21:35 ` Brian Foster
2014-09-05 0:45 ` Dave Chinner
2014-09-05 1:04 ` Eric Sandeen
2014-09-05 1:24 ` Dave Chinner [this message]
2014-09-05 11:02 ` Brian Foster
2014-09-05 11:19 ` Greg Freemyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140905012404.GV20518@dastard \
--to=david@fromorbit.com \
--cc=bfoster@redhat.com \
--cc=sandeen@sandeen.net \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox