Created attachment 83411 [details]
I've caught an issue slightly similar to the one discussed at
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
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
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.
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
> 3.2 or above (3.6.1 is still as well)
I mean 3.6.1 is affected as well
Does this go away if you mount without "relatime" ?
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...
Oh, and I should add the behavior is like this all the time ext3 exists.
> 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 :(
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?
> 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
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.
I see. Yes, for ext3 it's not easy as I wrote... So I'm closing the bug. And thanks for report anyway :).