From: "Torstem Bögershausen" <tboegi@web.de>
To: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>, "e@80x24.org" <e@80x24.org>
Subject: Re: [PATCH] t7063: work around FreeBSD's lazy mtime update feature
Date: Sun, 31 Jul 2016 22:37:28 -0300 [thread overview]
Message-ID: <6955746D-E47E-4BB8-AB0E-44D461E67AD6@web.de> (raw)
In-Reply-To: <20160730182005.14426-1-pclouds@gmail.com>
> Am 30.07.2016 um 15:20 schrieb Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
>
> Let's start with the commit message of [1] from freebsd.git [2]
>
> Sync timestamp changes for inodes of special files to disk as late
> as possible (when the inode is reclaimed). Temporarily only do
> this if option UFS_LAZYMOD configured and softupdates aren't
> enabled. UFS_LAZYMOD is intentionally left out of
> /sys/conf/options.
>
> This is mainly to avoid almost useless disk i/o on battery powered
> machines. It's silly to write to disk (on the next sync or when
> the inode becomes inactive) just because someone hit a key or
> something wrote to the screen or /dev/null.
>
> PR: 5577 [3]
>
> The short version of that, in the context of t7063, is that when a
> directory is updated, its mtime may be updated later, not
> immediately. This can be shown with a simple command sequence
>
> date; sleep 1; touch abc; rm abc; sleep 10; ls -lTd .
>
> One would expect that the date shown in `ls` would be one second from
> `date`, but it's 10 seconds later. If we put another `ls -lTd .` in
> front of `sleep 10`, then the date of the last `ls` comes as
> expected. The first `ls` somehow forces mtime to be updated.
>
> t7063 is really sensitive to directory mtime. When mtime is too "new",
> git code suspects racy timestamps and will not trigger the shortcut in
> untracked cache, in t7063.26 (or t7063.25 before this patch) and
> eventually be detected in t7063.28
>
> We have two options thanks to this special FreeBSD feature:
>
> 1) Stop supporting untracked cache on FreeBSD. Skip t7063 entirely
> when running on FreeBSD
>
> 2) Work around this problem (using the same 'ls' trick) and continue
> to support untracked cache on FreeBSD
>
> I initially wanted to go with 1) because I didn't know the exact
> nature of this feature and feared that it would make untracked cache
> work unreliably, using the cached version when it should not.
>
> Since the behavior of this thing is clearer now. The picture is not
> that bad. If this indeed happens often, untracked cache would assume
> racy condition more often and _fall back_ to non-untracked cache code
> paths. Which means it may be less effective, but it will not show
> wrong things.
>
> This patch goes with option 2.
>
> PS. For those who want to look further in FreeBSD source code, this
> flag is now called IN_LAZYMOD. I can see it's effective in ext2 and
> ufs. zfs is questionable.
>
> [1] 660e6408e6df99a20dacb070c5e7f9739efdf96d
> [2] git://github.com/freebsd/freebsd.git
> [3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=5577
>
> Reported-by: Eric Wong <e@80x24.org>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> This is only of those commits that commit messages are more important
> than the patch itself. One of the good notes about directory mtime,
> if we start to use it in more places in git.
>
> t/t7063-status-untracked-cache.sh | 4 ++++
> t/test-lib.sh | 6 ++++++
> 2 files changed, 10 insertions(+)
>
> diff --git a/t/t7063-status-untracked-cache.sh b/t/t7063-status-untracked-cache.sh
> index a971884..08fc586 100755
> --- a/t/t7063-status-untracked-cache.sh
> +++ b/t/t7063-status-untracked-cache.sh
> @@ -419,6 +419,10 @@ test_expect_success 'create/modify files, some of which are gitignored' '
> rm base
> '
>
> +test_expect_success FREEBSD 'Work around lazy mtime update' '
> + ls -ld . >/dev/null
> +'
> +
the term FREEBSD may be too generic to point out a single feature
in an OS distributution.
Following your investigations, it may even be possible that
other systems adapt this "feature"?
How about
LAZY_DIR_MTIME_UPDATE
(or similar)
next prev parent reply other threads:[~2016-08-01 1:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-18 22:30 t7063 failure on FreeBSD 10.3 i386/amd64 Eric Wong
2016-07-18 22:54 ` Eric Wong
2016-07-19 16:12 ` Duy Nguyen
2016-07-20 3:02 ` Eric Wong
2016-07-20 14:57 ` Duy Nguyen
2016-07-27 17:33 ` Duy Nguyen
2016-07-30 13:31 ` Duy Nguyen
2016-07-30 13:54 ` Duy Nguyen
2016-07-30 18:20 ` [PATCH] t7063: work around FreeBSD's lazy mtime update feature Nguyễn Thái Ngọc Duy
2016-07-31 0:15 ` Eric Wong
2016-07-31 1:07 ` Eric Wong
2016-07-31 14:30 ` Duy Nguyen
2016-08-01 1:37 ` Torstem Bögershausen [this message]
2016-08-01 17:10 ` Duy Nguyen
2016-08-01 21:04 ` Junio C Hamano
2016-08-02 15:37 ` Duy Nguyen
2016-08-02 17:17 ` Junio C Hamano
2016-08-03 16:05 ` [PATCH v2] " Nguyễn Thái Ngọc Duy
2016-08-03 16:16 ` Junio C Hamano
2016-08-03 16:25 ` Duy Nguyen
2016-08-03 17:45 ` [PATCH v3] " Nguyễn Thái Ngọc Duy
2016-08-03 17:52 ` Junio C Hamano
2016-08-03 19:07 ` Junio C Hamano
2016-08-04 15:46 ` Duy Nguyen
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6955746D-E47E-4BB8-AB0E-44D461E67AD6@web.de \
--to=tboegi@web.de \
--cc=e@80x24.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).