From: Brian Foster <bfoster@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Eric Sandeen <sandeen@sandeen.net>, xfs@oss.sgi.com
Subject: Re: [PATCH] xfsrestore: use utimensat() to provide atime/mtime with ns resolution
Date: Fri, 5 Sep 2014 07:02:12 -0400 [thread overview]
Message-ID: <20140905110211.GA3208@laptop.bfoster> (raw)
In-Reply-To: <20140905012404.GV20518@dastard>
On Fri, Sep 05, 2014 at 11:24:04AM +1000, Dave Chinner wrote:
> 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?
>
No problems that I'm aware of. As Eric mentioned, it was noticed during
an evaluation of possible data transfer mechanisms for a glusterfs
setup. The user had to evaluate whether it would lead to any issues (a
geo-replication tracking thing I suspect) for a customer, but I hadn't
heard anything that suggested it was. The utime() call appears to be
obsolete as well, for whatever that's worth.
Brian
> 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 11:07 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
2014-09-05 11:02 ` Brian Foster [this message]
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=20140905110211.GA3208@laptop.bfoster \
--to=bfoster@redhat.com \
--cc=david@fromorbit.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.