* Oops when Deleting Large File
@ 2003-01-21 17:19 Charles P. Wright
2003-01-21 20:21 ` Andrew Morton
0 siblings, 1 reply; 2+ messages in thread
From: Charles P. Wright @ 2003-01-21 17:19 UTC (permalink / raw)
To: linux-fsdevel
When testing a new disk array I created a large (1.4TB) file that filled
up the entire file system (dd ended with ENOSPC). After removing it I got
an Oops, the machine was totally locked, but I reproduced it over a serial
line. Attached is the original Oops and the Oops run through ksymoops
after a reboot.
This is using a RedHat stock kernel 2.4.18-19.8.0smp on 8.0. The file
system is ext3, and has a total of 1372158232 1k blocks.
Has anyone else seen this behavior?
Charles
[root@story data]# rm BIGFILE
rm: remove regular file `BIGFILE'? y
Assertion failure in do_get_write_access() at transaction.c:715: "handle->h_buffer_credits > 0"
------------[ cut here ]------------
kernel BUG at transaction.c:715!
invalid operand: 0000
binfmt_misc autofs sk98lin eepro100 iptable_filter ip_tables microcode mousedev keybdev hid input usb-ohci usbcore ext3 jbd 3w-xxxx sd_mod scsi_mod
CPU: 1
EIP: 0010:[<f8851e2c>] Not tainted
EFLAGS: 00010282
EIP is at do_get_write_access [jbd] 0x48c (2.4.18-19.8.0smp)
eax: 00000063 ebx: f5f80da0 ecx: c03b25f4 edx: f5dcfc9c
esi: f5de2c60 edi: f6be9a00 ebp: f7966440 esp: f5dcfcfc
ds: 0018 es: 0018 ss: 0018
Process rm (pid: 893, stackpage=f5dcf000)
Stack: f885a1c0 f8859b4e f8859ab0 000002cb f8859b7a 00000000 00000000 00000000
f5f80da0 00000259 00008000 f6b0a370 f88522c5 f5f80da0 f6b0a370 00000001
00000000 00000000 f6be9a94 f6be9a00 00000000 00000259 00008000 f6bce000
Call Trace: [<f885a1c0>] .rodata.str1.32 [jbd] 0x0 (0xf5dcfcfc))
[<f8859b4e>] .rodata.str1.1 [jbd] 0xae (0xf5dcfd00))
[<f8859ab0>] .rodata.str1.1 [jbd] 0x10 (0xf5dcfd04))
[<f8859b7a>] .rodata.str1.1 [jbd] 0xda (0xf5dcfd0c))
[<f88522c5>] journal_get_undo_access_Rsmp_10be8bf9 [jbd] 0x55 (0xf5dcfd2c))
[<f886067a>] ext3_free_blocks [ext3] 0x2fa (0xf5dcfd5c))
[<f88671c7>] ext3_do_update_inode [ext3] 0x177 (0xf5dcfd6c))
[<f8857b08>] log_start_commit_Rsmp_9edff2e4 [jbd] 0x98 (0xf5dcfdd4))
[<f885124a>] start_this_handle [jbd] 0xaa (0xf5dcfde0))
[<f88661ea>] ext3_clear_blocks [ext3] 0xca (0xf5dcfe0c))
[<f8866397>] ext3_free_data [ext3] 0xa7 (0xf5dcfe54))
[<f8863c04>] start_transaction [ext3] 0x94 (0xf5dcfe94))
[<f8866bc8>] ext3_truncate [ext3] 0x478 (0xf5dcfeac))
[<f885124a>] start_this_handle [jbd] 0xaa (0xf5dcfec8))
[<f8851445>] journal_start_Rsmp_cbe620c6 [jbd] 0xa5 (0xf5dcfef4))
[<f8863c04>] start_transaction [ext3] 0x94 (0xf5dcff18))
[<f8863dd9>] ext3_delete_inode [ext3] 0x159 (0xf5dcff30))
[<f8869eb0>] ext3_unlink [ext3] 0x150 (0xf5dcff38))
[<f8863c80>] ext3_delete_inode [ext3] 0x0 (0xf5dcff44))
[<c0163be9>] iput [kernel] 0x149 (0xf5dcff4c))
[<c0158e35>] vfs_unlink [kernel] 0x185 (0xf5dcff68))
[<c01590a9>] sys_unlink [kernel] 0x119 (0xf5dcff84))
[<c010944f>] system_call [kernel] 0x33 (0xf5dcffc0))
Code: 0f 0b cb 02 b0 9a 85 f8 8b 4c 24 34 8b 41 04 e9 4c ff ff ff
Segmentation fault
ksymoops 2.4.5 on i686 2.4.18-19.8.0smp. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.18-19.8.0smp/ (default)
-m /boot/System.map-2.4.18-19.8.0smp (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Error (expand_objects): cannot stat(/lib/ext3.o) for ext3
Error (expand_objects): cannot stat(/lib/jbd.o) for jbd
Error (expand_objects): cannot stat(/lib/3w-xxxx.o) for 3w-xxxx
Error (expand_objects): cannot stat(/lib/sd_mod.o) for sd_mod
Error (expand_objects): cannot stat(/lib/scsi_mod.o) for scsi_mod
Warning (map_ksym_to_module): cannot match loaded module ext3 to a unique module object. Trace may not be reliable.
kernel BUG at transaction.c:715!
invalid operand: 0000
CPU: 1
EIP: 0010:[<f8851e2c>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 00000063 ebx: f5f80da0 ecx: c03b25f4 edx: f5dcfc9c
esi: f5de2c60 edi: f6be9a00 ebp: f7966440 esp: f5dcfcfc
ds: 0018 es: 0018 ss: 0018
Process rm (pid: 893, stackpage=f5dcf000)
Stack: f885a1c0 f8859b4e f8859ab0 000002cb f8859b7a 00000000 00000000 00000000
f5f80da0 00000259 00008000 f6b0a370 f88522c5 f5f80da0 f6b0a370 00000001
00000000 00000000 f6be9a94 f6be9a00 00000000 00000259 00008000 f6bce000
Call Trace: [<f885a1c0>] .rodata.str1.32 [jbd] 0x0 (0xf5dcfcfc))
[<f8859b4e>] .rodata.str1.1 [jbd] 0xae (0xf5dcfd00))
[<f8859ab0>] .rodata.str1.1 [jbd] 0x10 (0xf5dcfd04))
[<f8859b7a>] .rodata.str1.1 [jbd] 0xda (0xf5dcfd0c))
[<f88522c5>] journal_get_undo_access_Rsmp_10be8bf9 [jbd] 0x55 (0xf5dcfd2c))
[<f886067a>] ext3_free_blocks [ext3] 0x2fa (0xf5dcfd5c))
[<f88671c7>] ext3_do_update_inode [ext3] 0x177 (0xf5dcfd6c))
[<f8857b08>] log_start_commit_Rsmp_9edff2e4 [jbd] 0x98 (0xf5dcfdd4))
[<f885124a>] start_this_handle [jbd] 0xaa (0xf5dcfde0))
[<f88661ea>] ext3_clear_blocks [ext3] 0xca (0xf5dcfe0c))
[<f8866397>] ext3_free_data [ext3] 0xa7 (0xf5dcfe54))
[<f8863c04>] start_transaction [ext3] 0x94 (0xf5dcfe94))
[<f8866bc8>] ext3_truncate [ext3] 0x478 (0xf5dcfeac))
[<f885124a>] start_this_handle [jbd] 0xaa (0xf5dcfec8))
[<f8851445>] journal_start_Rsmp_cbe620c6 [jbd] 0xa5 (0xf5dcfef4))
[<f8863c04>] start_transaction [ext3] 0x94 (0xf5dcff18))
[<f8863dd9>] ext3_delete_inode [ext3] 0x159 (0xf5dcff30))
[<f8869eb0>] ext3_unlink [ext3] 0x150 (0xf5dcff38))
[<f8863c80>] ext3_delete_inode [ext3] 0x0 (0xf5dcff44))
[<c0163be9>] iput [kernel] 0x149 (0xf5dcff4c))
[<c0158e35>] vfs_unlink [kernel] 0x185 (0xf5dcff68))
[<c01590a9>] sys_unlink [kernel] 0x119 (0xf5dcff84))
[<c010944f>] system_call [kernel] 0x33 (0xf5dcffc0))
Code: 0f 0b cb 02 b0 9a 85 f8 8b 4c 24 34 8b 41 04 e9 4c ff ff ff
>>EIP; f8851e2c <[jbd]do_get_write_access+48c/610> <=====
>>ebx; f5f80da0 <_end+35b35f60/383db220>
>>ecx; c03b25f4 <runqueues+d74/13400>
>>edx; f5dcfc9c <_end+35984e5c/383db220>
>>esi; f5de2c60 <_end+35997e20/383db220>
>>edi; f6be9a00 <_end+3679ebc0/383db220>
>>ebp; f7966440 <_end+3751b600/383db220>
>>esp; f5dcfcfc <_end+35984ebc/383db220>
Trace; f885a1c0 <[jbd]__kstrtab_journal_force_commit+198/4d60>
Trace; f8859b4e <[jbd]__kstrtab_journal_get_create_access+26/40>
Trace; f8859ab0 <[jbd]__ksymtab_journal_ack_err+0/8>
Trace; f8859b7a <[jbd]__kstrtab_journal_get_undo_access+12/40>
Trace; f88522c5 <[jbd]journal_get_undo_access+55/140>
Trace; f886067a <[ext3].text.start+61a/d4bd>
Trace; f88671c7 <[ext3].text.start+7167/d4bd>
Trace; f8857b08 <[jbd]log_start_commit+98/c0>
Trace; f885124a <[jbd]start_this_handle+aa/190>
Trace; f88661ea <[ext3].text.start+618a/d4bd>
Trace; f8866397 <[ext3].text.start+6337/d4bd>
Trace; f8863c04 <[ext3].text.start+3ba4/d4bd>
Trace; f8866bc8 <[ext3].text.start+6b68/d4bd>
Trace; f885124a <[jbd]start_this_handle+aa/190>
Trace; f8851445 <[jbd]journal_start+a5/c0>
Trace; f8863c04 <[ext3].text.start+3ba4/d4bd>
Trace; f8863dd9 <[ext3].text.start+3d79/d4bd>
Trace; f8869eb0 <[ext3].text.start+9e50/d4bd>
Trace; f8863c80 <[ext3].text.start+3c20/d4bd>
Trace; c0163be9 <iput+149/2c0>
Trace; c0158e35 <vfs_unlink+185/2e0>
Trace; c01590a9 <sys_unlink+119/120>
Trace; c010944f <system_call+33/38>
Code; f8851e2c <[jbd]do_get_write_access+48c/610>
00000000 <_EIP>:
Code; f8851e2c <[jbd]do_get_write_access+48c/610> <=====
0: 0f 0b ud2a <=====
Code; f8851e2e <[jbd]do_get_write_access+48e/610>
2: cb lret
Code; f8851e2f <[jbd]do_get_write_access+48f/610>
3: 02 b0 9a 85 f8 8b add 0x8bf8859a(%eax),%dh
Code; f8851e35 <[jbd]do_get_write_access+495/610>
9: 4c dec %esp
Code; f8851e36 <[jbd]do_get_write_access+496/610>
a: 24 34 and $0x34,%al
Code; f8851e38 <[jbd]do_get_write_access+498/610>
c: 8b 41 04 mov 0x4(%ecx),%eax
Code; f8851e3b <[jbd]do_get_write_access+49b/610>
f: e9 4c ff ff ff jmp ffffff60 <_EIP+0xffffff60>
2 warnings and 5 errors issued. Results may not be reliable.
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: Oops when Deleting Large File
2003-01-21 17:19 Oops when Deleting Large File Charles P. Wright
@ 2003-01-21 20:21 ` Andrew Morton
0 siblings, 0 replies; 2+ messages in thread
From: Andrew Morton @ 2003-01-21 20:21 UTC (permalink / raw)
To: Charles P. Wright; +Cc: linux-fsdevel
"Charles P. Wright" wrote:
>
> When testing a new disk array I created a large (1.4TB) file that filled
> up the entire file system (dd ended with ENOSPC). After removing it I got
> an Oops, the machine was totally locked, but I reproduced it over a serial
> line. Attached is the original Oops and the Oops run through ksymoops
> after a reboot.
>
> This is using a RedHat stock kernel 2.4.18-19.8.0smp on 8.0. The file
> system is ext3, and has a total of 1372158232 1k blocks.
>
> Has anyone else seen this behavior?
>
Not really. Could be related to this fix (which I forgot
to send to Marcelo, oops)
Under rare conditions (filesystem corruption, really) it is possible
for ext3_dirty_inode() to require _two_ blocks for the transaction: one
for the inode and one to update the superblock - to set
EXT3_FEATURE_RO_COMPAT_LARGE_FILE. This causes the filesystem to go
BUG.
So reserve an additional block for that eventuality.
fs/ext3/inode.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- 25/fs/ext3/inode.c~ext3-transaction-reserved-blocks Sat Dec 14 18:28:21 2002
+++ 25-akpm/fs/ext3/inode.c Sat Dec 14 18:28:21 2002
@@ -2698,7 +2698,7 @@ void ext3_dirty_inode(struct inode *inod
handle_t *handle;
lock_kernel();
- handle = ext3_journal_start(inode, 1);
+ handle = ext3_journal_start(inode, 2);
if (IS_ERR(handle))
goto out;
if (current_handle &&
_
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2003-01-21 20:21 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-01-21 17:19 Oops when Deleting Large File Charles P. Wright
2003-01-21 20:21 ` Andrew Morton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).