From: john stultz <johnstul@us.ibm.com>
To: "Petr Titěra" <P.Titera@century.cz>
Cc: "Petr Titěra" <petr@titera.eu>, linux-kernel@vger.kernel.org
Subject: Re: Wrong atime on recent kernels
Date: Thu, 17 Dec 2009 19:13:41 -0800 [thread overview]
Message-ID: <1261106021.3466.76.camel@localhost.localdomain> (raw)
In-Reply-To: <4B2A1051.9010808@century.cz>
On Thu, 2009-12-17 at 12:04 +0100, Petr Titěra wrote:
> john stultz napsal(a):
> > On Wed, 2009-12-16 at 21:55 +0100, Petr Titěra wrote:
> >
> >> john stultz napsal(a):
> >>
> >>> 2009/12/14 Petr Titěra <petr@titera.eu>:
> >>>
> >>>
> >>>> Hello,
> >>>>
> >>>> I see some strange file modification times recently. It seems to me
> >>>> that in some situations, kernel allows to set nanoseconds part of file
> >>>> access, modification or change time to 100000000 ns. Problem seems to be in
> >>>> some generic part of kernel because I see it on several different
> >>>> filesysytems (ext4 and nilf2). These is I've got during my testing on kernel
> >>>> 2.6.32-tip-08309-gad8e75a.
> >>>>
> >>>> File: `./Documentation/dvb/contributors.txt'
> >>>> Size: 3035 Blocks: 8 IO Block: 4096 regular file
> >>>> Device: fe04h/65028d Inode: 818 Links: 1
> >>>> Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
> >>>> Access: 2009-12-14 10:29:04.1000000000 +0100
> >>>> Modify: 2009-12-14 10:29:04.1000000000 +0100
> >>>> Change: 2009-12-14 10:29:04.1000000000 +0100
> >>>>
> >>>> See that all times of that file ends with 1e6 nanoseconds.
> >>>>
> >> I did not test reverting this patch yet, because I did not find
> >> reliable way how to reproduce these strange modify times. But as I
> >> read your description. Would it be possible that if there would be bug
> >> in your patch i would be observer on mostly quiet system? I'm asking
> >> because full day of testing of the system under load did not produce
> >> any result, but then when I tried to run "find / | xargs stat" on idle
> >> system I've got several new instances of wrong access time (filesystem
> >> is mounted without noatime)
> >>
> >
> > Another quick question:
> >
> > What is the normal behavior you see when this issue is not cropping up?
> >
> > Do you normally see all 0's in the ns field? Or do you expect to see an
> > actual ns value?
> >
> >
> Sorry to reply again. Previous message did not get to list:
>
> I see values which seems to be ns times there. My root filesystem is
> ext4 too (recently I do not remeber if I formated it from scratch when I
> reinstalled that system) but I see this happen on other filesystems too
>
> Root filesystem (ext4 may be converted from ext3)
>
> File: `/etc/sysconfig'
> Size: 4096 Blocks: 8 IO Block: 4096 directory
> Device: fe00h/65024d Inode: 65282 Links: 7
> Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
> Access: 2009-12-16 21:14:00.172000000 +0100
> Modify: 2009-12-12 11:01:48.1000000000 +0100
> Change: 2009-12-12 11:01:48.1000000000 +0100
> File: `/etc/sysconfig/prelink'
> Size: 1459 Blocks: 8 IO Block: 4096 regular file
> Device: fe00h/65024d Inode: 22706 Links: 1
> Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
> Access: 2009-12-14 10:27:46.912000002 +0100
> Modify: 2004-11-23 11:43:08.000000000 +0100
> Change: 2009-12-08 22:57:24.656000002 +0100
> File: `/etc/sysconfig/i18n'
> Size: 47 Blocks: 8 IO Block: 4096 regular file
> Device: fe00h/65024d Inode: 48962 Links: 1
> Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
> Access: 2010-08-27 18:07:21.500013018 +0200
> Modify: 2009-06-22 23:33:43.113581313 +0200
> Change: 2009-06-22 23:58:39.936318201 +0200
So I'm not reproducing this with 2.6.33-rc1 on a fresh ext4 partition on
x68_64.
File: `virt'
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 804h/2052d Inode: 1868440 Links: 3
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2009-12-17 21:22:44.692710730 -0500
Modify: 2009-12-17 20:14:40.000000000 -0500
Change: 2009-12-17 21:20:21.001915208 -0500
File: `vmlinux'
Size: 21122497 Blocks: 24136 IO Block: 4096 regular file
Device: 804h/2052d Inode: 1874435 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2009-12-17 21:22:05.381691121 -0500
Modify: 2009-12-17 21:22:05.376691754 -0500
Change: 2009-12-17 21:22:05.376691754 -0500
File: `vmlinux.o'
Size: 16701780 Blocks: 32624 IO Block: 4096 regular file
Device: 804h/2052d Inode: 1874418 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2009-12-17 21:22:01.138228732 -0500
Modify: 2009-12-17 21:22:01.131229619 -0500
Change: 2009-12-17 21:22:01.131229619 -0500
Let me know if you find anything that helps narrow this down.
thanks
-john
next prev parent reply other threads:[~2009-12-18 3:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-14 21:17 Wrong atime on recent kernels Petr Titěra
2009-12-14 21:41 ` Andi Kleen
2009-12-14 21:59 ` Petr Titěra
2009-12-14 21:45 ` john stultz
[not found] ` <4B29494B.4010305@titera.eu>
2009-12-17 1:21 ` john stultz
2009-12-17 3:26 ` john stultz
2009-12-17 11:04 ` Petr Titěra
2009-12-17 21:19 ` john stultz
2009-12-18 3:13 ` john stultz [this message]
2009-12-20 22:29 ` Petr Titěra
2009-12-20 23:31 ` Petr Titěra
2009-12-21 21:16 ` john stultz
2009-12-22 15:50 ` Petr Titěra
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=1261106021.3466.76.camel@localhost.localdomain \
--to=johnstul@us.ibm.com \
--cc=P.Titera@century.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=petr@titera.eu \
/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.