Bug 48751

Summary:	ext3: ctime changes with no reason in 30 seconds after a file change
Product:	File System	Reporter:	Vladimir A. Pavlov (pv4)
Component:	ext3	Assignee:	Jan Kara (jack)
Status:	RESOLVED WILL_NOT_FIX
Severity:	normal	CC:	alan, jack, pv4
Priority:	P1
Hardware:	IA-32
OS:	Linux
Kernel Version:	2.6.35+, maybe older	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	Details

Description Vladimir A. Pavlov 2012-10-13 18:07:33 UTC

Created attachment 83411 [details]
Details

I've caught an issue slightly similar to the one discussed at
http://git.661346.n2.nabble.com/BUG-Working-tree-getting-out-of-date-quot-spontaneously-quot-td3029928.html
but in my case the issueexists if mounting ext3 partition using
native ext3 module, not ext3 mode of ext4 module.

How to reproduce:
   I'm sorry I haven't found an easier way to reproduce the issue. I
   hope the issue is obvious enough for those who works on ext2/3/4
   modules to understand and fix it using the strace and stat output
   provided.
   Steps 2 and 3 are just preparations, the actual issue appears
   in step 4.
1. Have an ext3 partition mounted using the native ext3 module
   (mounting ext3 partition using ext4 module works fine but it has
   different issues so I cannot use it).
   I tested both slackware-14 (32bit) default kernel and the 3.6.1
   from www.kernel.org.
2. Download and unpack glibc-2.16.0.tar.xz from ftp.gnu.org,
   build it using ./configure --prefix=/usr && make
3. rm -rf /tmp/a && mkdir /tmp/a
4. make install_root=/tmp/a localedata/install-locales
   During this step /tmp/a/usr/lib/locale/locale-archive is created and
   modified which we have the problem with.
5. Wait until 1-2 locale names are printed to the console (it takes
   about 5 seconds) and press Ctrl+C (not pressing Ctrl+C also causes
   the issue to happed but requires much more time to finish).
6. stat /tmp/a/usr/lib/locale/locale-archive to see the current status
7. wait ~30-40 seconds
8. stat /tmp/a/usr/lib/locale/locale-archive to see the changed
   "Change time" and "Blocks"

Sometimes the issue is not reproducable. But 3 runs of steps 3-8 always
reproduce the issue for me at least once.

Affected versions:
3.2 or above (3.6.1 is still as well)
3.0 is not affected
3.1 cannot test 3.1 right now to tell you whether it's affected or not.
    If it really matters, tell me and I'll test it ASAP.

Attachment archive contents:
filesystems  : /proc/filesystems
modules      : /proc/modules
mounts       : /proc/mounts
process-list : ps auxww
stat         : stat results
strace       : strace -fo strace make install_root=/tmp/a localedata/install-locales
tune2fs-l    : tune2fs -l
version      : /proc/version

Comment 1 Vladimir A. Pavlov 2012-10-13 18:11:20 UTC

> 3.2 or above (3.6.1 is still as well)

I mean 3.6.1 is affected as well

Comment 2 Alan 2012-10-14 12:28:12 UTC

Does this go away if you mount without "relatime" ?

Comment 3 Vladimir A. Pavlov 2012-10-15 17:41:42 UTC

No

Comment 4 Jan Kara 2012-10-17 22:52:55 UTC

Yeah, the reason is that /tmp/a/usr/lib/locale/locale-archive is written to via mmap. ext3 (since it does not support delayed allocation) allocates blocks for the written data only when flusher thread decides to do writeback on the inode (which is 30s after the file is written). This allocation changes i_blocks field of the inode and thus inode's ctime has to be changed as well.

I understand this is counter-intuitive but that's just how the filesystem works...

Comment 5 Jan Kara 2012-10-17 22:54:39 UTC

Oh, and I should add the behavior is like this all the time ext3 exists.

Comment 6 Vladimir A. Pavlov 2012-10-21 15:47:36 UTC

> Oh, and I should add the behavior is like this all the time ext3 exists.

Oops... You are right.

I've just rechecked. It actually exists in 2.6.35 as well. So, it's not a regression.

Any chances it will be fixed? Otherwise I have to think about moving to ext4 :(

Comment 7 Jan Kara 2012-10-29 10:21:42 UTC

As much as I understand ctime update is unexpected at the first sight, it is technically a correct thing to do as writeback *does* change what stat(2) returns (st_blocks field). So I don't plan to change the behavior for ext3 and potentially break some applications relying on ctime changing whenever inode changes.

Of course more complex fix of performing delayed allocation and thus updating i_blocks earlier is possible as well. I actually suggested something like that about an year ago but it's a rather complex change and people were concerned about introducing bugs to a filesystem which is in maintenance-only mode. So that didn't happen.

BTW: What problems does delayed ctime update cause to your applications?

Comment 8 Vladimir A. Pavlov 2012-10-29 16:12:02 UTC

> What problems does delayed ctime update cause to your applications?

I have a script to create binary tarball of glibc. It does

...
make install_root=/tmp/glibc localedata/install-locales
cd /tmp/glibc
tar -cJf /tmp/glibc-2.16.0-bin.tar.xz .

tar detects ctime change during its run and prints a warning like "usr/lib/locale/locale-archve: file changed as we read it". This seemed unlogically for me (and still does) and looked like a kernel bug so I reported it. I can of course redirect tar output to /dev/null or just ignore the warning if it's really hard to fix the issue.

Comment 9 Jan Kara 2012-10-29 18:33:00 UTC

I see. Yes, for ext3 it's not easy as I wrote... So I'm closing the bug. And thanks for report anyway :).