Messages in this thread | | | Date | Sun, 20 Dec 2009 23:29:48 +0100 | From | Petr Titěra <> | Subject | Re: Wrong atime on recent kernels |
| |
john stultz napsal(a): > 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. > > Hello,
I know its far fetched, but is there something what is preventing xtime.tv_nsec to be exactly 999999999 near the end of update_wall_time in kernel/time/timekeeping.c?
Petr
> thanks > -john > > > >
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |