search for: ext3_sync_fil

------------[ cut here ]------------ kernel BUG at fs/ext3/fsync.c:50! invalid operand: 0000 [#1] CPU: 0 EIP: 0060:[<b0187d38>] Not tainted VLI EFLAGS: 00010296 (2.6.13.1) EIP is at ext3_sync_file+0x58/0xf0 eax: 00000068 ebx: bf4a479c ecx: b03cffac edx: b03cffac esi: b0398cfc edi: b2b8f1c8 ebp: c13bcf60 esp: c13bcf18 ds: 007b es: 007b ss: 0068 Process aptitude (pid: 26952, threadinfo=c13bc000 task=d99cca80) Stack: b0398afc b0383f40 b0395746 00000032 b0398cfc 00000000 0000000...

...inode+0x197/0x2a3 Apr 11 10:13:29 server kernel: [<c045ee18>] do_writepages+0x2b/0x32 Apr 11 10:13:29 server kernel: [<c045a96c>] __filemap_fdatawrite_range+0x66/0x72 Apr 11 10:13:29 server kernel: [<c0496346>] sync_inode+0x19/0x24 Apr 11 10:13:29 server kernel: [<f8983009>] ext3_sync_file+0xb1/0xdc [ext3] Apr 11 10:13:29 server kernel: [<c047956c>] do_fsync+0x41/0x83 Apr 11 10:13:29 server kernel: [<c04795cb>] __do_fsync+0x1d/0x2b Apr 11 10:13:29 server kernel: [<c0404f4b>] syscall_call+0x7/0xb Apr 11 10:13:29 server kernel: ======================= Apr 11 10:13:29...

...age was not shown between "write: in ..." and "fsync: out ...". The problem was occurred since 2.6.5-bk1, which includes the patch "[PATCH] ext3 fsync() and fdatasync() speedup". We found that the problem was solved by deleting the part of the patch which modifies ext3_sync_file(). Maybe, i_state is not correctly set to I_DIRTY when the related page cache is dirty (is it true?) Attached file is tarball (tar + bzip2) which contains following files. The patches are for 2.6.8.1-kernel (applicable to 2.6.9-rc2), and the results were also produced with 2.6.8.1-kernel. - fs...

...:jbd:log_wait_commit+0xa3/0xf5 [<ffffffff800a34a8>] autoremove_wake_function+0x0/0x2e [<ffffffff8803179a>] :jbd:journal_stop+0x1d3/0x203 [<ffffffff8002f96a>] __writeback_single_inode+0x1dd/0x31c [<ffffffff800f7454>] sync_inode+0x24/0x33 [<ffffffff8804c37e>] :ext3:ext3_sync_file+0xce/0xf8 [<ffffffff8004fe60>] do_fsync+0x52/0xa4 [<ffffffff800e48c9>] __do_fsync+0x23/0x36 [<ffffffff8005d28d>] tracesys+0xd5/0xe0 INFO: task VBoxHeadless:20743 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this m...

...y those nfsd threads above are waiting on kjournald. But what is kjournald really waiting for? My first though was the two nfsd threads in: nfsd Call Trace: [sleep_on+75/124] [log_wait_commit+74/136] [journal_stop+408/432] [journal_force_commit+78/128] [ext3_force_commit+66/112] [ext3_sync_file+128/144] [nfsd_sync_dir+49/72] [nfsd_unlink+455/480] [nfsd_proc_remove+122/140] [nfsd_dispatch+207/406] [svc_process+655/1264] [nfsd+566/944] [arch_kernel_thread+40/56] that are waiting on j_wait_done_commit. However they are doing that from journal_stop *after* journal_stop has decrem...

...emory and the unmount will silently discard it. The fix is to only apply the optimisation to inodes which are operating under data=ordered. --- linux-akpm/fs/ext3/fsync.c~ext3-fsync-fix Sat Nov 30 23:37:33 2002 +++ linux-akpm-akpm/fs/ext3/fsync.c Sat Nov 30 23:39:30 2002 @@ -63,10 +63,12 @@ int ext3_sync_file(struct file * file, s */ ret = fsync_inode_buffers(inode); - /* In writeback mode, we need to force out data buffers too. In - * the other modes, ext3_force_commit takes care of forcing out - * just the right data blocks. */ - if (test_opt(inode->i_sb, DATA_FLAGS) == EXT3_MOUNT_WRITEB...

Has anyone tried LFS (ie >2G files support) and Ext3 together? Are there good reasons why this should/should not work? I see the RH enterprise kernel patch set specifically does not attempt both lfs and ext3, but the lfs patches themselves touch some reasonably localised parts of ext2, so I would hope (without having dived in there to test), that the ext3 changes would mirror that