Bug 48751 - ext3: ctime changes with no reason in 30 seconds after a file change
Summary: ext3: ctime changes with no reason in 30 seconds after a file change
Status: RESOLVED WILL_NOT_FIX
Alias: None
Product: File System
Classification: Unclassified
Component: ext3 (show other bugs)
Hardware: IA-32 Linux
: P1 normal
Assignee: Jan Kara
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-13 18:07 UTC by Vladimir A. Pavlov
Modified: 2012-10-29 18:33 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.35+, maybe older
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Details (96.26 KB, application/octet-stream)
2012-10-13 18:07 UTC, Vladimir A. Pavlov
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 :).

Note You need to log in before you can comment on or make changes to this bug.