From jpeter16 at yahoo.com Thu Jun 3 21:34:38 2004 From: jpeter16 at yahoo.com (jiju peter) Date: Thu, 3 Jun 2004 14:34:38 -0700 (PDT) Subject: write system call returning success after SCSI write failure Message-ID: <20040603213438.85071.qmail@web40312.mail.yahoo.com> I am running RHEL3 server connected to a JBOD using a fiber channel HBA. I mounted a disk using ext3 file system with -o sync option on directory /mntb. Then I unplugged the fiber channel cable and did following commands. echo 1 > /tmp/file1 cp /tmp/file1 /mntb/file echo $? The cp command waited for 30 seconds and there are SCSI and file system error messages on the console as expected. I am sure that the data did not reach the fiber channel disk. But the exit status of cp command is zero. This is an strace of cp command ==== open("/mntb/file", O_WRONLY|O_TRUNC|O_LARGEFILE) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0 read(3, "2\n", 4096) = 2 write(4, "2\n", 2) = 2 read(3, "", 4096) = 0 close(4) = 0 close(3) = 0 =========== Looks like files system is not propagating the error to the system call. With the sync option in mount command I expected the open and write system calls to fail if I/O to FC disk returned error. I repeated this test using two vendor's fiber channel HBAs. Both gave same result. I can see SCSI commands returning with error. Is this expected behavior with ext3-fs mounted with sync option? thanks, J Peter __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ From pla at morecom.no Mon Jun 7 08:21:50 2004 From: pla at morecom.no (Petter Larsen) Date: Mon, 07 Jun 2004 10:21:50 +0200 Subject: mode data=journal. Is it safe to use? Message-ID: <1086596509.1812.22.camel@pla.lokal.lan> Hello I can see several postings on this mailing-list that people have problem with mounting ext3 partition with mode data=journal. See URL's: https://www.redhat.com/archives/ext3-users/2004-March/msg00000.html https://www.redhat.com/archives/ext3-users/2004-March/msg00050.html We are going to use ext3 on a Compact Flash disk in true IDE mode. We need this filesystem to be as safe and consistent as possible. We can not tolerate any garbage in the files after a crash or sudden power failures. We have then decided to use ext3 with mode data=journal. Can I rely on this? We use kernel 2.6.5 on PowerPC 8260, and may be using newer kernels later in the project. Best regards -- Petter Larsen cand. scient. moreCom as 913 17 222 From krh at os.is Tue Jun 8 10:02:32 2004 From: krh at os.is (Kjartan Reynir Hauksson) Date: Tue, 8 Jun 2004 10:02:32 +0000 Subject: Directories turned to sockets Message-ID: A couple of days ago I noticed that a 117 directories in one of my logical volumes had turned to sockets wich fsck does not seem to fix. All the affected folders(sockets) have the following attributes srwxr-xr-x 32770 2147516917 2147516917 2147520512 and they all report the same size of 1073758212 (1.1T). Does anyone have an explanation as to how this could happen and more importandly is there a way to reverse this ? My system is Mandrake 10 with kernel 2.6.3-8mdk, if you need more info then just ask. Regards -Kjartan Reynir Hauksson. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pla at morecom.no Thu Jun 10 08:57:20 2004 From: pla at morecom.no (Petter Larsen) Date: Thu, 10 Jun 2004 10:57:20 +0200 Subject: mode data=journal. Is it safe to use? In-Reply-To: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> Message-ID: <1086857839.2960.3.camel@pla.lokal.lan> Hello I can see that the threads that I have referenced is crash in the 2.4.x kernel. We use kerrnel 2.6.x. Are there major updates in this kernel for ext3 or are they much alike the latest 2.4.x kernels? Petter On Mon, 2004-06-07 at 10:21, Petter Larsen wrote: > Hello > > I can see several postings on this mailing-list that people have > problem > with mounting ext3 partition with mode data=journal. > > See URL's: > https://www.redhat.com/archives/ext3-users/2004-March/msg00000.html > https://www.redhat.com/archives/ext3-users/2004-March/msg00050.html > > We are going to use ext3 on a Compact Flash disk in true IDE mode. We > need this filesystem to be as safe and consistent as possible. We can > not tolerate any garbage in the files after a crash or sudden power > failures. We have then decided to use ext3 with mode data=journal. > > Can I rely on this? > We use kernel 2.6.5 on PowerPC 8260, and may be using newer kernels > later in the project. > > > Best regards > -- > Petter Larsen > cand. scient. > moreCom as > 913 17 222 > > > _______________________________________________ > Ext3-users mailing list > Ext3-users at redhat.com > https://www.redhat.com/mailman/listinfo/ext3-users -- Petter Larsen cand. scient. moreCom as 913 17 222 From Ralf.Hildebrandt at charite.de Thu Jun 10 09:27:49 2004 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Thu, 10 Jun 2004 11:27:49 +0200 Subject: ext3 EIP Message-ID: <20040610092749.GX9012@charite.de> I hope this EIP can enlightend the developers: Jun 10 10:28:59 shawarma kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000019 Jun 10 10:28:59 shawarma kernel: printing eip: Jun 10 10:28:59 shawarma kernel: c0181d47 Jun 10 10:28:59 shawarma kernel: *pde = 00000000 Jun 10 10:28:59 shawarma kernel: Oops: 0000 [#1] Jun 10 10:28:59 shawarma kernel: Modules linked in: n_hdlc ppp_synctty ipv6 autofs ipt_TCPMSS ipt_MASQUERADE iptable_nat ip_conntrack iptable_filter ip_tables snd_ens1371 snd_rawmidi snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_timer snd_ac97_codec snd soundcore uhci_hcd usbcore via_agp agpgart 3c59x Jun 10 10:28:59 shawarma kernel: CPU: 0 Jun 10 10:28:59 shawarma kernel: EIP: 0060:[journal_grab_journal_head+7/32] Not tainted Jun 10 10:28:59 shawarma kernel: EFLAGS: 00010213 (2.6.7-rc2-bk5) Jun 10 10:28:59 shawarma kernel: EIP is at journal_grab_journal_head+0x7/0x20 Jun 10 10:28:59 shawarma kernel: eax: 00000019 ebx: 00000019 ecx: 00000000 edx: 00000019 Jun 10 10:28:59 shawarma kernel: esi: 00000000 edi: d6fee20c ebp: c10074c0 esp: cdef7be4 Jun 10 10:28:59 shawarma kernel: ds: 007b es: 007b ss: 0068 Jun 10 10:28:59 shawarma kernel: Process aide (pid: 14762, threadinfo=cdef7000 task=d45d4810) Jun 10 10:28:59 shawarma kernel: Stack: c017d58d 00000000 d7fc74b8 c0172300 000001d2 cdef7ce0 c10074c0 c0145f78 Jun 10 10:28:59 shawarma kernel: d6870324 00000000 c0134c1a cdef7ce0 00000001 00000011 00000000 cdef7d88 Jun 10 10:28:59 shawarma kernel: 000001d2 cdef7c28 cdef7c28 cdef7c70 cdef7c74 c017137e cdef7c74 c01714c5 Jun 10 10:28:59 shawarma kernel: Call Trace: Jun 10 10:28:59 shawarma kernel: [journal_try_to_free_buffers+45/160] journal_try_to_free_buffers+0x2d/0xa0 Jun 10 10:28:59 shawarma kernel: [ext3_releasepage+0/96] ext3_releasepage+0x0/0x60 Jun 10 10:28:59 shawarma kernel: [try_to_release_page+56/96] try_to_release_page+0x38/0x60 Jun 10 10:28:59 shawarma kernel: [shrink_list+826/1056] shrink_list+0x33a/0x420 Jun 10 10:28:59 shawarma kernel: [ext3_get_block_handle+126/704] ext3_get_block_handle+0x7e/0x2c0 Jun 10 10:28:59 shawarma kernel: [ext3_get_block_handle+453/704] ext3_get_block_handle+0x1c5/0x2c0 Jun 10 10:28:59 shawarma kernel: [__ide_dma_begin+34/64] __ide_dma_begin+0x22/0x40 Jun 10 10:28:59 shawarma kernel: [shrink_cache+314/768] shrink_cache+0x13a/0x300 Jun 10 10:28:59 shawarma kernel: [shrink_zone+170/288] shrink_zone+0xaa/0x120 Jun 10 10:28:59 shawarma kernel: [shrink_caches+92/128] shrink_caches+0x5c/0x80 Jun 10 10:28:59 shawarma kernel: [try_to_free_pages+148/384] try_to_free_pages+0x94/0x180 Jun 10 10:28:59 shawarma kernel: [__alloc_pages+422/768] __alloc_pages+0x1a6/0x300 Jun 10 10:28:59 shawarma kernel: [do_page_cache_readahead+231/288] do_page_cache_readahead+0xe7/0x120 Jun 10 10:28:59 shawarma kernel: [filemap_nopage+705/800] filemap_nopage+0x2c1/0x320 Jun 10 10:28:59 shawarma kernel: [do_no_page+144/672] do_no_page+0x90/0x2a0 Jun 10 10:28:59 shawarma kernel: [handle_mm_fault+166/256] handle_mm_fault+0xa6/0x100 Jun 10 10:28:59 shawarma kernel: [do_page_fault+263/1181] do_page_fault+0x107/0x49d Jun 10 10:28:59 shawarma kernel: [recalc_task_prio+139/384] recalc_task_prio+0x8b/0x180 Jun 10 10:28:59 shawarma kernel: [schedule+605/1056] schedule+0x25d/0x420 Jun 10 10:28:59 shawarma kernel: [do_IRQ+271/352] do_IRQ+0x10f/0x160 Jun 10 10:28:59 shawarma kernel: [do_page_fault+0/1181] do_page_fault+0x0/0x49d Jun 10 10:28:59 shawarma kernel: [error_code+45/64] error_code+0x2d/0x40 Jun 10 10:28:59 shawarma kernel: Jun 10 10:28:59 shawarma kernel: Code: 8b 00 f6 c4 08 74 06 8b 4a 24 ff 41 04 89 c8 c3 89 f6 8d bc Jun 10 10:28:59 shawarma kernel: printing eip: Jun 10 10:28:59 shawarma kernel: c0181d47 Jun 10 10:28:59 shawarma kernel: Oops: 0000 [#1] Jun 10 10:28:59 shawarma kernel: Modules linked in: n_hdlc ppp_synctty ipv6 autofs ipt_TCPMSS ipt_MASQUERADE iptable_nat ip_conntrack iptable_filter ip_tables snd_ens1371 snd_rawmidi snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_timer snd_ac97_codec snd soundcore uhci_hcd usbcore via_agp agpgart 3c59x Jun 10 10:28:59 shawarma kernel: CPU: 0 Jun 10 10:28:59 shawarma kernel: EIP: 0060:[journal_grab_journal_head+7/32] Not tainted Jun 10 10:28:59 shawarma kernel: EFLAGS: 00010213 (2.6.7-rc2-bk5) Jun 10 10:28:59 shawarma kernel: EIP is at journal_grab_journal_head+0x7/0x20 Jun 10 10:28:59 shawarma kernel: eax: 00000019 ebx: 00000019 ecx: 00000000 edx: 00000019 Jun 10 10:28:59 shawarma kernel: esi: 00000000 edi: d6fee20c ebp: c10074c0 esp: cdef7be4 Jun 10 10:28:59 shawarma kernel: ds: 007b es: 007b ss: 0068 Jun 10 10:28:59 shawarma kernel: Process aide (pid: 14762, threadinfo=cdef7000 task=d45d4810) Jun 10 10:28:59 shawarma kernel: Stack: c017d58d 00000000 d7fc74b8 c0172300 000001d2 cdef7ce0 c10074c0 c0145f78 Jun 10 10:28:59 shawarma kernel: d6870324 00000000 c0134c1a cdef7ce0 00000001 00000011 00000000 cdef7d88 Jun 10 10:28:59 shawarma kernel: 000001d2 cdef7c28 cdef7c28 cdef7c70 cdef7c74 c017137e cdef7c74 c01714c5 Jun 10 10:28:59 shawarma kernel: Call Trace: Jun 10 10:28:59 shawarma kernel: [journal_try_to_free_buffers+45/160] journal_try_to_free_buffers+0x2d/0xa0 Jun 10 10:28:59 shawarma kernel: [ext3_releasepage+0/96] ext3_releasepage+0x0/0x60 Jun 10 10:28:59 shawarma kernel: [try_to_release_page+56/96] try_to_release_page+0x38/0x60 Jun 10 10:28:59 shawarma kernel: [shrink_list+826/1056] shrink_list+0x33a/0x420 Jun 10 10:28:59 shawarma kernel: [ext3_get_block_handle+126/704] ext3_get_block_handle+0x7e/0x2c0 Jun 10 10:28:59 shawarma kernel: [ext3_get_block_handle+453/704] ext3_get_block_handle+0x1c5/0x2c0 Jun 10 10:28:59 shawarma kernel: [__ide_dma_begin+34/64] __ide_dma_begin+0x22/0x40 Jun 10 10:28:59 shawarma kernel: [shrink_cache+314/768] shrink_cache+0x13a/0x300 Jun 10 10:28:59 shawarma kernel: [shrink_zone+170/288] shrink_zone+0xaa/0x120 Jun 10 10:28:59 shawarma kernel: [shrink_caches+92/128] shrink_caches+0x5c/0x80 Jun 10 10:28:59 shawarma kernel: [try_to_free_pages+148/384] try_to_free_pages+0x94/0x180 Jun 10 10:28:59 shawarma kernel: [__alloc_pages+422/768] __alloc_pages+0x1a6/0x300 Jun 10 10:28:59 shawarma kernel: [do_page_cache_readahead+231/288] do_page_cache_readahead+0xe7/0x120 Jun 10 10:28:59 shawarma kernel: [filemap_nopage+705/800] filemap_nopage+0x2c1/0x320 Jun 10 10:28:59 shawarma kernel: [do_no_page+144/672] do_no_page+0x90/0x2a0 Jun 10 10:28:59 shawarma kernel: [handle_mm_fault+166/256] handle_mm_fault+0xa6/0x100 Jun 10 10:28:59 shawarma kernel: [do_page_fault+263/1181] do_page_fault+0x107/0x49d Jun 10 10:28:59 shawarma kernel: [recalc_task_prio+139/384] recalc_task_prio+0x8b/0x180 Jun 10 10:28:59 shawarma kernel: [schedule+605/1056] schedule+0x25d/0x420 Jun 10 10:28:59 shawarma kernel: [do_IRQ+271/352] do_IRQ+0x10f/0x160 Jun 10 10:28:59 shawarma kernel: [do_page_fault+0/1181] do_page_fault+0x0/0x49d Jun 10 10:28:59 shawarma kernel: [error_code+45/64] error_code+0x2d/0x40 Jun 10 10:28:59 shawarma kernel: Jun 10 10:28:59 shawarma kernel: Code: 8b 00 f6 c4 08 74 06 8b 4a 24 ff 41 04 89 c8 c3 89 f6 8d bc Jun 10 10:28:59 shawarma kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000019 Jun 10 10:28:59 shawarma kernel: printing eip: Jun 10 10:28:59 shawarma kernel: c0181d47 Jun 10 10:28:59 shawarma kernel: *pde = 00000000 Jun 10 10:28:59 shawarma kernel: Oops: 0000 [#1] Jun 10 10:28:59 shawarma kernel: Modules linked in: n_hdlc ppp_synctty ipv6 autofs ipt_TCPMSS ipt_MASQUERADE iptable_nat ip_conntrack iptable_filter ip_tables snd_ens1371 snd_rawmidi snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_timer snd_ac97_codec snd soundcore uhci_hcd usbcore via_agp agpgart 3c59x Jun 10 10:28:59 shawarma kernel: CPU: 0 Jun 10 10:28:59 shawarma kernel: EIP: 0060:[journal_grab_journal_head+7/32] Not tainted Jun 10 10:28:59 shawarma kernel: EFLAGS: 00010213 (2.6.7-rc2-bk5) Jun 10 10:28:59 shawarma kernel: EIP is at journal_grab_journal_head+0x7/0x20 Jun 10 10:28:59 shawarma kernel: eax: 00000019 ebx: 00000019 ecx: 00000000 edx: 00000019 Jun 10 10:28:59 shawarma kernel: esi: 00000000 edi: d6fee20c ebp: c10074c0 esp: cdef7be4 Jun 10 10:28:59 shawarma kernel: ds: 007b es: 007b ss: 0068 Jun 10 10:28:59 shawarma kernel: Process aide (pid: 14762, threadinfo=cdef7000 task=d45d4810) Jun 10 10:28:59 shawarma kernel: Stack: c017d58d 00000000 d7fc74b8 c0172300 000001d2 cdef7ce0 c10074c0 c0145f78 Jun 10 10:28:59 shawarma kernel: d6870324 00000000 c0134c1a cdef7ce0 00000001 00000011 00000000 cdef7d88 Jun 10 10:28:59 shawarma kernel: 000001d2 cdef7c28 cdef7c28 cdef7c70 cdef7c74 c017137e cdef7c74 c01714c5 Jun 10 10:28:59 shawarma kernel: Call Trace: Jun 10 10:28:59 shawarma kernel: [journal_try_to_free_buffers+45/160] journal_try_to_free_buffers+0x2d/0xa0 Jun 10 10:28:59 shawarma kernel: [ext3_releasepage+0/96] ext3_releasepage+0x0/0x60 Jun 10 10:28:59 shawarma kernel: [try_to_release_page+56/96] try_to_release_page+0x38/0x60 Jun 10 10:28:59 shawarma kernel: [shrink_list+826/1056] shrink_list+0x33a/0x420 Jun 10 10:28:59 shawarma kernel: [ext3_get_block_handle+126/704] ext3_get_block_handle+0x7e/0x2c0 Jun 10 10:28:59 shawarma kernel: [ext3_get_block_handle+453/704] ext3_get_block_handle+0x1c5/0x2c0 Jun 10 10:28:59 shawarma kernel: [__ide_dma_begin+34/64] __ide_dma_begin+0x22/0x40 Jun 10 10:28:59 shawarma kernel: [shrink_cache+314/768] shrink_cache+0x13a/0x300 Jun 10 10:28:59 shawarma kernel: [shrink_zone+170/288] shrink_zone+0xaa/0x120 Jun 10 10:28:59 shawarma kernel: [shrink_caches+92/128] shrink_caches+0x5c/0x80 Jun 10 10:28:59 shawarma kernel: [try_to_free_pages+148/384] try_to_free_pages+0x94/0x180 Jun 10 10:28:59 shawarma kernel: [__alloc_pages+422/768] __alloc_pages+0x1a6/0x300 Jun 10 10:28:59 shawarma kernel: [do_page_cache_readahead+231/288] do_page_cache_readahead+0xe7/0x120 Jun 10 10:28:59 shawarma kernel: [filemap_nopage+705/800] filemap_nopage+0x2c1/0x320 Jun 10 10:28:59 shawarma kernel: [do_no_page+144/672] do_no_page+0x90/0x2a0 Jun 10 10:28:59 shawarma kernel: [handle_mm_fault+166/256] handle_mm_fault+0xa6/0x100 Jun 10 10:28:59 shawarma kernel: [do_page_fault+263/1181] do_page_fault+0x107/0x49d Jun 10 10:28:59 shawarma kernel: [recalc_task_prio+139/384] recalc_task_prio+0x8b/0x180 Jun 10 10:28:59 shawarma kernel: [schedule+605/1056] schedule+0x25d/0x420 Jun 10 10:28:59 shawarma kernel: [do_IRQ+271/352] do_IRQ+0x10f/0x160 Jun 10 10:28:59 shawarma kernel: [do_page_fault+0/1181] do_page_fault+0x0/0x49d Jun 10 10:28:59 shawarma kernel: [error_code+45/64] error_code+0x2d/0x40 Jun 10 10:28:59 shawarma kernel: Jun 10 10:28:59 shawarma kernel: Code: 8b 00 f6 c4 08 74 06 8b 4a 24 ff 41 04 89 c8 c3 89 f6 8d bc -- Ralf Hildebrandt (Im Auftrag des Referat V a) Ralf.Hildebrandt at charite.de Charite - Universit?tsmedizin Berlin Tel. +49 (0)30-450 570-155 Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-916 IT-Zentrum Standort Campus Mitte AIM. ralfpostfix From pla at morecom.no Thu Jun 10 10:24:43 2004 From: pla at morecom.no (Petter Larsen) Date: Thu, 10 Jun 2004 12:24:43 +0200 Subject: ext3 EIP In-Reply-To: <20040610092749.GX9012@charite.de> References: <20040610092749.GX9012@charite.de> Message-ID: <1086863083.2960.7.camel@pla.lokal.lan> Which mode are you using? data=journal|ordered|writeback? Petter On Thu, 2004-06-10 at 11:27, Ralf Hildebrandt wrote: > I hope this EIP can enlightend the developers: > > Jun 10 10:28:59 shawarma kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000019 > Jun 10 10:28:59 shawarma kernel: printing eip: > Jun 10 10:28:59 shawarma kernel: c0181d47 > Jun 10 10:28:59 shawarma kernel: *pde = 00000000 > Jun 10 10:28:59 shawarma kernel: Oops: 0000 [#1] > Jun 10 10:28:59 shawarma kernel: Modules linked in: n_hdlc ppp_synctty ipv6 autofs ipt_TCPMSS ipt_MASQUERADE iptable_nat ip_conntrack iptable_filter ip_tables snd_ens1371 snd_rawmidi snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_timer snd_ac97_codec snd soundcore uhci_hcd usbcore via_agp agpgart 3c59x > Jun 10 10:28:59 shawarma kernel: CPU: 0 > Jun 10 10:28:59 shawarma kernel: EIP: 0060:[journal_grab_journal_head+7/32] Not tainted > Jun 10 10:28:59 shawarma kernel: EFLAGS: 00010213 (2.6.7-rc2-bk5) > Jun 10 10:28:59 shawarma kernel: EIP is at journal_grab_journal_head+0x7/0x20 > Jun 10 10:28:59 shawarma kernel: eax: 00000019 ebx: 00000019 ecx: 00000000 edx: 00000019 > Jun 10 10:28:59 shawarma kernel: esi: 00000000 edi: d6fee20c ebp: c10074c0 esp: cdef7be4 > Jun 10 10:28:59 shawarma kernel: ds: 007b es: 007b ss: 0068 > Jun 10 10:28:59 shawarma kernel: Process aide (pid: 14762, threadinfo=cdef7000 task=d45d4810) > Jun 10 10:28:59 shawarma kernel: Stack: c017d58d 00000000 d7fc74b8 c0172300 000001d2 cdef7ce0 c10074c0 c0145f78 > Jun 10 10:28:59 shawarma kernel: d6870324 00000000 c0134c1a cdef7ce0 00000001 00000011 00000000 cdef7d88 > Jun 10 10:28:59 shawarma kernel: 000001d2 cdef7c28 cdef7c28 cdef7c70 cdef7c74 c017137e cdef7c74 c01714c5 > Jun 10 10:28:59 shawarma kernel: Call Trace: > Jun 10 10:28:59 shawarma kernel: [journal_try_to_free_buffers+45/160] journal_try_to_free_buffers+0x2d/0xa0 > Jun 10 10:28:59 shawarma kernel: [ext3_releasepage+0/96] ext3_releasepage+0x0/0x60 > Jun 10 10:28:59 shawarma kernel: [try_to_release_page+56/96] try_to_release_page+0x38/0x60 > Jun 10 10:28:59 shawarma kernel: [shrink_list+826/1056] shrink_list+0x33a/0x420 > Jun 10 10:28:59 shawarma kernel: [ext3_get_block_handle+126/704] ext3_get_block_handle+0x7e/0x2c0 > Jun 10 10:28:59 shawarma kernel: [ext3_get_block_handle+453/704] ext3_get_block_handle+0x1c5/0x2c0 > Jun 10 10:28:59 shawarma kernel: [__ide_dma_begin+34/64] __ide_dma_begin+0x22/0x40 > Jun 10 10:28:59 shawarma kernel: [shrink_cache+314/768] shrink_cache+0x13a/0x300 > Jun 10 10:28:59 shawarma kernel: [shrink_zone+170/288] shrink_zone+0xaa/0x120 > Jun 10 10:28:59 shawarma kernel: [shrink_caches+92/128] shrink_caches+0x5c/0x80 > Jun 10 10:28:59 shawarma kernel: [try_to_free_pages+148/384] try_to_free_pages+0x94/0x180 > Jun 10 10:28:59 shawarma kernel: [__alloc_pages+422/768] __alloc_pages+0x1a6/0x300 > Jun 10 10:28:59 shawarma kernel: [do_page_cache_readahead+231/288] do_page_cache_readahead+0xe7/0x120 > Jun 10 10:28:59 shawarma kernel: [filemap_nopage+705/800] filemap_nopage+0x2c1/0x320 > Jun 10 10:28:59 shawarma kernel: [do_no_page+144/672] do_no_page+0x90/0x2a0 > Jun 10 10:28:59 shawarma kernel: [handle_mm_fault+166/256] handle_mm_fault+0xa6/0x100 > Jun 10 10:28:59 shawarma kernel: [do_page_fault+263/1181] do_page_fault+0x107/0x49d > Jun 10 10:28:59 shawarma kernel: [recalc_task_prio+139/384] recalc_task_prio+0x8b/0x180 > Jun 10 10:28:59 shawarma kernel: [schedule+605/1056] schedule+0x25d/0x420 > Jun 10 10:28:59 shawarma kernel: [do_IRQ+271/352] do_IRQ+0x10f/0x160 > Jun 10 10:28:59 shawarma kernel: [do_page_fault+0/1181] do_page_fault+0x0/0x49d > Jun 10 10:28:59 shawarma kernel: [error_code+45/64] error_code+0x2d/0x40 > Jun 10 10:28:59 shawarma kernel: > Jun 10 10:28:59 shawarma kernel: Code: 8b 00 f6 c4 08 74 06 8b 4a 24 ff 41 04 89 c8 c3 89 f6 8d bc > Jun 10 10:28:59 shawarma kernel: printing eip: > Jun 10 10:28:59 shawarma kernel: c0181d47 > Jun 10 10:28:59 shawarma kernel: Oops: 0000 [#1] > Jun 10 10:28:59 shawarma kernel: Modules linked in: n_hdlc ppp_synctty ipv6 autofs ipt_TCPMSS ipt_MASQUERADE iptable_nat ip_conntrack iptable_filter ip_tables snd_ens1371 snd_rawmidi snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_timer snd_ac97_codec snd soundcore uhci_hcd usbcore via_agp agpgart 3c59x > Jun 10 10:28:59 shawarma kernel: CPU: 0 > Jun 10 10:28:59 shawarma kernel: EIP: 0060:[journal_grab_journal_head+7/32] Not tainted > Jun 10 10:28:59 shawarma kernel: EFLAGS: 00010213 (2.6.7-rc2-bk5) > Jun 10 10:28:59 shawarma kernel: EIP is at journal_grab_journal_head+0x7/0x20 > Jun 10 10:28:59 shawarma kernel: eax: 00000019 ebx: 00000019 ecx: 00000000 edx: 00000019 > Jun 10 10:28:59 shawarma kernel: esi: 00000000 edi: d6fee20c ebp: c10074c0 esp: cdef7be4 > Jun 10 10:28:59 shawarma kernel: ds: 007b es: 007b ss: 0068 > Jun 10 10:28:59 shawarma kernel: Process aide (pid: 14762, threadinfo=cdef7000 task=d45d4810) > Jun 10 10:28:59 shawarma kernel: Stack: c017d58d 00000000 d7fc74b8 c0172300 000001d2 cdef7ce0 c10074c0 c0145f78 > Jun 10 10:28:59 shawarma kernel: d6870324 00000000 c0134c1a cdef7ce0 00000001 00000011 00000000 cdef7d88 > Jun 10 10:28:59 shawarma kernel: 000001d2 cdef7c28 cdef7c28 cdef7c70 cdef7c74 c017137e cdef7c74 c01714c5 > Jun 10 10:28:59 shawarma kernel: Call Trace: > Jun 10 10:28:59 shawarma kernel: [journal_try_to_free_buffers+45/160] journal_try_to_free_buffers+0x2d/0xa0 > Jun 10 10:28:59 shawarma kernel: [ext3_releasepage+0/96] ext3_releasepage+0x0/0x60 > Jun 10 10:28:59 shawarma kernel: [try_to_release_page+56/96] try_to_release_page+0x38/0x60 > Jun 10 10:28:59 shawarma kernel: [shrink_list+826/1056] shrink_list+0x33a/0x420 > Jun 10 10:28:59 shawarma kernel: [ext3_get_block_handle+126/704] ext3_get_block_handle+0x7e/0x2c0 > Jun 10 10:28:59 shawarma kernel: [ext3_get_block_handle+453/704] ext3_get_block_handle+0x1c5/0x2c0 > Jun 10 10:28:59 shawarma kernel: [__ide_dma_begin+34/64] __ide_dma_begin+0x22/0x40 > Jun 10 10:28:59 shawarma kernel: [shrink_cache+314/768] shrink_cache+0x13a/0x300 > Jun 10 10:28:59 shawarma kernel: [shrink_zone+170/288] shrink_zone+0xaa/0x120 > Jun 10 10:28:59 shawarma kernel: [shrink_caches+92/128] shrink_caches+0x5c/0x80 > Jun 10 10:28:59 shawarma kernel: [try_to_free_pages+148/384] try_to_free_pages+0x94/0x180 > Jun 10 10:28:59 shawarma kernel: [__alloc_pages+422/768] __alloc_pages+0x1a6/0x300 > Jun 10 10:28:59 shawarma kernel: [do_page_cache_readahead+231/288] do_page_cache_readahead+0xe7/0x120 > Jun 10 10:28:59 shawarma kernel: [filemap_nopage+705/800] filemap_nopage+0x2c1/0x320 > Jun 10 10:28:59 shawarma kernel: [do_no_page+144/672] do_no_page+0x90/0x2a0 > Jun 10 10:28:59 shawarma kernel: [handle_mm_fault+166/256] handle_mm_fault+0xa6/0x100 > Jun 10 10:28:59 shawarma kernel: [do_page_fault+263/1181] do_page_fault+0x107/0x49d > Jun 10 10:28:59 shawarma kernel: [recalc_task_prio+139/384] recalc_task_prio+0x8b/0x180 > Jun 10 10:28:59 shawarma kernel: [schedule+605/1056] schedule+0x25d/0x420 > Jun 10 10:28:59 shawarma kernel: [do_IRQ+271/352] do_IRQ+0x10f/0x160 > Jun 10 10:28:59 shawarma kernel: [do_page_fault+0/1181] do_page_fault+0x0/0x49d > Jun 10 10:28:59 shawarma kernel: [error_code+45/64] error_code+0x2d/0x40 > Jun 10 10:28:59 shawarma kernel: > Jun 10 10:28:59 shawarma kernel: Code: 8b 00 f6 c4 08 74 06 8b 4a 24 ff 41 04 89 c8 c3 89 f6 8d bc > Jun 10 10:28:59 shawarma kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000019 > Jun 10 10:28:59 shawarma kernel: printing eip: > Jun 10 10:28:59 shawarma kernel: c0181d47 > Jun 10 10:28:59 shawarma kernel: *pde = 00000000 > Jun 10 10:28:59 shawarma kernel: Oops: 0000 [#1] > Jun 10 10:28:59 shawarma kernel: Modules linked in: n_hdlc ppp_synctty ipv6 autofs ipt_TCPMSS ipt_MASQUERADE iptable_nat ip_conntrack iptable_filter ip_tables snd_ens1371 snd_rawmidi snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_timer snd_ac97_codec snd soundcore uhci_hcd usbcore via_agp agpgart 3c59x > Jun 10 10:28:59 shawarma kernel: CPU: 0 > Jun 10 10:28:59 shawarma kernel: EIP: 0060:[journal_grab_journal_head+7/32] Not tainted > Jun 10 10:28:59 shawarma kernel: EFLAGS: 00010213 (2.6.7-rc2-bk5) > Jun 10 10:28:59 shawarma kernel: EIP is at journal_grab_journal_head+0x7/0x20 > Jun 10 10:28:59 shawarma kernel: eax: 00000019 ebx: 00000019 ecx: 00000000 edx: 00000019 > Jun 10 10:28:59 shawarma kernel: esi: 00000000 edi: d6fee20c ebp: c10074c0 esp: cdef7be4 > Jun 10 10:28:59 shawarma kernel: ds: 007b es: 007b ss: 0068 > Jun 10 10:28:59 shawarma kernel: Process aide (pid: 14762, threadinfo=cdef7000 task=d45d4810) > Jun 10 10:28:59 shawarma kernel: Stack: c017d58d 00000000 d7fc74b8 c0172300 000001d2 cdef7ce0 c10074c0 c0145f78 > Jun 10 10:28:59 shawarma kernel: d6870324 00000000 c0134c1a cdef7ce0 00000001 00000011 00000000 cdef7d88 > Jun 10 10:28:59 shawarma kernel: 000001d2 cdef7c28 cdef7c28 cdef7c70 cdef7c74 c017137e cdef7c74 c01714c5 > Jun 10 10:28:59 shawarma kernel: Call Trace: > Jun 10 10:28:59 shawarma kernel: [journal_try_to_free_buffers+45/160] journal_try_to_free_buffers+0x2d/0xa0 > Jun 10 10:28:59 shawarma kernel: [ext3_releasepage+0/96] ext3_releasepage+0x0/0x60 > Jun 10 10:28:59 shawarma kernel: [try_to_release_page+56/96] try_to_release_page+0x38/0x60 > Jun 10 10:28:59 shawarma kernel: [shrink_list+826/1056] shrink_list+0x33a/0x420 > Jun 10 10:28:59 shawarma kernel: [ext3_get_block_handle+126/704] ext3_get_block_handle+0x7e/0x2c0 > Jun 10 10:28:59 shawarma kernel: [ext3_get_block_handle+453/704] ext3_get_block_handle+0x1c5/0x2c0 > Jun 10 10:28:59 shawarma kernel: [__ide_dma_begin+34/64] __ide_dma_begin+0x22/0x40 > Jun 10 10:28:59 shawarma kernel: [shrink_cache+314/768] shrink_cache+0x13a/0x300 > Jun 10 10:28:59 shawarma kernel: [shrink_zone+170/288] shrink_zone+0xaa/0x120 > Jun 10 10:28:59 shawarma kernel: [shrink_caches+92/128] shrink_caches+0x5c/0x80 > Jun 10 10:28:59 shawarma kernel: [try_to_free_pages+148/384] try_to_free_pages+0x94/0x180 > Jun 10 10:28:59 shawarma kernel: [__alloc_pages+422/768] __alloc_pages+0x1a6/0x300 > Jun 10 10:28:59 shawarma kernel: [do_page_cache_readahead+231/288] do_page_cache_readahead+0xe7/0x120 > Jun 10 10:28:59 shawarma kernel: [filemap_nopage+705/800] filemap_nopage+0x2c1/0x320 > Jun 10 10:28:59 shawarma kernel: [do_no_page+144/672] do_no_page+0x90/0x2a0 > Jun 10 10:28:59 shawarma kernel: [handle_mm_fault+166/256] handle_mm_fault+0xa6/0x100 > Jun 10 10:28:59 shawarma kernel: [do_page_fault+263/1181] do_page_fault+0x107/0x49d > Jun 10 10:28:59 shawarma kernel: [recalc_task_prio+139/384] recalc_task_prio+0x8b/0x180 > Jun 10 10:28:59 shawarma kernel: [schedule+605/1056] schedule+0x25d/0x420 > Jun 10 10:28:59 shawarma kernel: [do_IRQ+271/352] do_IRQ+0x10f/0x160 > Jun 10 10:28:59 shawarma kernel: [do_page_fault+0/1181] do_page_fault+0x0/0x49d > Jun 10 10:28:59 shawarma kernel: [error_code+45/64] error_code+0x2d/0x40 > Jun 10 10:28:59 shawarma kernel: > Jun 10 10:28:59 shawarma kernel: Code: 8b 00 f6 c4 08 74 06 8b 4a 24 ff 41 04 89 c8 c3 89 f6 8d bc -- Petter Larsen cand. scient. moreCom as 913 17 222 From Ralf.Hildebrandt at charite.de Thu Jun 10 10:27:10 2004 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Thu, 10 Jun 2004 12:27:10 +0200 Subject: ext3 EIP In-Reply-To: <1086863083.2960.7.camel@pla.lokal.lan> References: <20040610092749.GX9012@charite.de> <1086863083.2960.7.camel@pla.lokal.lan> Message-ID: <20040610102710.GN9012@charite.de> * Petter Larsen : > Which mode are you using? > > data=journal|ordered|writeback? The default, ordered -- Ralf Hildebrandt (Im Auftrag des Referat V a) Ralf.Hildebrandt at charite.de Charite - Universit?tsmedizin Berlin Tel. +49 (0)30-450 570-155 Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-916 IT-Zentrum Standort Campus Mitte AIM. ralfpostfix From ga-thrawn at gmx.de Fri Jun 11 13:09:07 2004 From: ga-thrawn at gmx.de (=?ISO-8859-1?B?SW5nbyBL9nN0ZXI=?=) Date: Fri, 11 Jun 2004 15:09:07 +0200 Subject: Problems recovering data from broken disk Message-ID: <471476278.20040611150907@gmx.de> Hi, maybe someone could help me out here: I have a broken disk with serveral partitions (1-3 primary, 4 extended and 5-6 logical). I am able to get access to the primary partions and already recovered the data. I can see all partitions using fdisk -l /dev/hdc. But I cannot mount the logical ones: mount -t ext3 /dev/hdc5 /mnt mount: wrong fs type, bad option, bad superblock on /dev/hdc5, or too many mounted file systems As fsck don't run, I tried to look for the backup-superblock with mke2fs -n /dev/hdc5 but it says: Device size reported to be zero. ... And this is the point where I am lost. Is there still way to mount this partitions? Many thanks any ideas. Ingo From pla at morecom.no Fri Jun 11 13:14:32 2004 From: pla at morecom.no (Petter Larsen) Date: Fri, 11 Jun 2004 15:14:32 +0200 Subject: Problems recovering data from broken disk In-Reply-To: <471476278.20040611150907@gmx.de> References: <471476278.20040611150907@gmx.de> Message-ID: <1086959672.1683.14.camel@pla.lokal.lan> You may want to look at debugfs... Petter On Fri, 2004-06-11 at 15:09, Ingo K?ster wrote: > Hi, > > maybe someone could help me out here: > > I have a broken disk with serveral partitions (1-3 primary, 4 > extended and 5-6 logical). I am able to get access to the primary > partions and already recovered the data. > > I can see all partitions using fdisk -l /dev/hdc. > > But I cannot mount the logical ones: > > mount -t ext3 /dev/hdc5 /mnt > mount: wrong fs type, bad option, bad superblock on /dev/hdc5, > or too many mounted file systems > > As fsck don't run, I tried to look for the backup-superblock with > mke2fs -n /dev/hdc5 but it says: Device size reported to be zero. ... > > And this is the point where I am lost. Is there still way to mount > this partitions? Many thanks any ideas. > > Ingo > > > _______________________________________________ > Ext3-users mailing list > Ext3-users at redhat.com > https://www.redhat.com/mailman/listinfo/ext3-users -- Petter Larsen cand. scient. moreCom as 913 17 222 From ga-thrawn at gmx.de Fri Jun 11 13:42:18 2004 From: ga-thrawn at gmx.de (=?ISO-8859-1?B?SW5nbyBL9nN0ZXI=?=) Date: Fri, 11 Jun 2004 15:42:18 +0200 Subject: Problems recovering data from broken disk In-Reply-To: <1086959672.1683.14.camel@pla.lokal.lan> References: <471476278.20040611150907@gmx.de> <1086959672.1683.14.camel@pla.lokal.lan> Message-ID: <1046291255.20040611154218@gmx.de> > You may want to look at debugfs... Thanks, I already took a look at debugfs...but at starup it says: Invalid argument while opening filesystem when typing "debugfs /dev/hdc5". Ingo From linuxtard at yahoo.com Sat Jun 12 06:41:16 2004 From: linuxtard at yahoo.com (Linux Tard) Date: Fri, 11 Jun 2004 23:41:16 -0700 (PDT) Subject: Problems recovering data from broken disk In-Reply-To: <471476278.20040611150907@gmx.de> Message-ID: <20040612064116.51051.qmail@web41008.mail.yahoo.com> Info have you tried gpart on a dd image file clone? - lt --- Ingo K?ster wrote: > Hi, > > maybe someone could help me out here: > > I have a broken disk with serveral partitions (1-3 > primary, 4 > extended and 5-6 logical). I am able to get access > to the primary > partions and already recovered the data. > > I can see all partitions using fdisk -l /dev/hdc. > > But I cannot mount the logical ones: > > mount -t ext3 /dev/hdc5 /mnt > mount: wrong fs type, bad option, bad > superblock on /dev/hdc5, > or too many mounted file systems > > As fsck don't run, I tried to look for the > backup-superblock with > mke2fs -n /dev/hdc5 but it says: Device size > reported to be zero. ... > > And this is the point where I am lost. Is there > still way to mount > this partitions? Many thanks any ideas. > > Ingo > > > _______________________________________________ > Ext3-users mailing list > Ext3-users at redhat.com > https://www.redhat.com/mailman/listinfo/ext3-users __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ From vinu at wave.ees.hokudai.ac.jp Tue Jun 15 02:33:39 2004 From: vinu at wave.ees.hokudai.ac.jp (Vinu K V) Date: 15 Jun 2004 11:33:39 +0900 Subject: ext3 data recovery in RH9, help please Message-ID: <1087266818.5345.21.camel@wave.ees.hokudai.ac.jp> Hi users, I was working with GNU parted and got some changes in the partition and the system crashed. I had to freshly install RH Linux 9 again as it didn't detect the linux installation. Now the problem is /dev/hda is mounted but not showing any data files. It has full of data originally. Anyhow Can i recover those data. I didnt format any of the hard drive expect the root partition for fresh installation. Any hope left with me? /dev/hdb had two partitions and it is mounted and detected all files well. The problem is with /dev/hda which has two major partitions /home and /user2. The df commands gives as follows Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda1 3020140 1675368 1191356 59% / /dev/hda3 50394996 32856 47802184 1% /home none 515096 0 515096 0% /dev/shm /dev/hda4 64191716 32856 60898068 1% /user2 /dev/hdb1 60476036 46272440 11131568 81% /user3 /dev/hdb2 48172868 41662356 4063412 92% /user4 From adilger at clusterfs.com Tue Jun 15 16:18:22 2004 From: adilger at clusterfs.com (Andreas Dilger) Date: Tue, 15 Jun 2004 10:18:22 -0600 Subject: ext3 data recovery in RH9, help please In-Reply-To: <1087266818.5345.21.camel@wave.ees.hokudai.ac.jp> References: <1087266818.5345.21.camel@wave.ees.hokudai.ac.jp> Message-ID: <20040615161822.GE7570@schnapps.adilger.int> On Jun 15, 2004 11:33 +0900, Vinu K V wrote: > I was working with GNU parted and got some changes in the partition and > the system crashed. I had to freshly install RH Linux 9 again as it > didn't detect the linux installation. Now the problem > is /dev/hda is mounted but not showing any data files. It has > full of data originally. Anyhow Can i recover those data. > I didnt format any of the hard drive expect the root > partition for fresh installation. Any hope left with me? > /dev/hdb had two partitions and it is mounted and detected > all files well. The problem is with /dev/hda which has two > major partitions /home and /user2. The df commands gives as follows > > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/hda1 3020140 1675368 1191356 59% / > /dev/hda3 50394996 32856 47802184 1% /home > none 515096 0 515096 0% /dev/shm > /dev/hda4 64191716 32856 60898068 1% /user2 > /dev/hdb1 60476036 46272440 11131568 81% /user3 > /dev/hdb2 48172868 41662356 4063412 92% /user4 It would appear that your reinstall, or parted, reformatted your filesystems. The usage "32856" is almost certainly only the journal file. In situations like this it is much better to boot from a rescue CD (or a floppy even, like Tom's Root Boot disk) and do the recovery before something so dangerous as installing a new operating system. If you are looking for text files, you might try: strings -n 20 -t d /dev/hda3 | grep "important data" and then use dd to copy the data from the offset reported by strings: dd if=/dev/hda3 of=/user3/file bs=4k skip= count=N Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pla at morecom.no Tue Jun 15 18:09:37 2004 From: pla at morecom.no (Petter Larsen) Date: Tue, 15 Jun 2004 20:09:37 +0200 Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> Message-ID: <1087322976.1874.36.camel@pla.lokal.lan> Hello I try again. Can anybody of you acknowledge or not if mode data=journal in ext3 is safe to use in Linux kernel 2.6.x? Wee need to have a very consistent and integrity for our filesystem, and it would then be desired to journal both data and metadata. But if this mode can corrupt the filesystem as both Phil White and Nicolas Kowalski has experienced, it may be more advised to use mode data=ordered instead. Data integrity is much more important for us than speed. What do you people out there say? I also try to post this in the kernel mailing list. I have not subscribed to the kml so if anybody there have som advisory about this I would be pleased if you could CC me. Petter On Mon, 2004-06-07 at 10:21, Petter Larsen wrote: > Hello > > I can see several postings on this mailing-list that people have > problem > with mounting ext3 partition with mode data=journal. > > See URL's: > https://www.redhat.com/archives/ext3-users/2004-March/msg00000.html > https://www.redhat.com/archives/ext3-users/2004-March/msg00050.html > > We are going to use ext3 on a Compact Flash disk in true IDE mode. We > need this filesystem to be as safe and consistent as possible. We can > not tolerate any garbage in the files after a crash or sudden power > failures. We have then decided to use ext3 with mode data=journal. > > Can I rely on this? > We use kernel 2.6.5 on PowerPC 8260, and may be using newer kernels > later in the project. > > > Best regards > -- > Petter Larsen > cand. scient. > moreCom as > 913 17 222 > > > _______________________________________________ > Ext3-users mailing list > Ext3-users at redhat.com > https://www.redhat.com/mailman/listinfo/ext3-users -- Petter Larsen cand. scient. moreCom as 913 17 222 From crosser at rol.ru Tue Jun 15 18:20:02 2004 From: crosser at rol.ru (Eugene Crosser) Date: Tue, 15 Jun 2004 22:20:02 +0400 Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <1087322976.1874.36.camel@pla.lokal.lan> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> Message-ID: <1087323602.16701.42.camel@ariel.sovam.com> On Tue, 2004-06-15 at 20:09 +0200, Petter Larsen wrote: > Can anybody of you acknowledge or not if mode data=journal in ext3 is > safe to use in Linux kernel 2.6.x? > > Wee need to have a very consistent and integrity for our filesystem, and > it would then be desired to journal both data and metadata. > > But if this mode can corrupt the filesystem as both Phil White and > Nicolas Kowalski has experienced, it may be more advised to use mode > data=ordered instead. > > Data integrity is much more important for us than speed. I ran ext3 with data=journal on 2.6.6smp for about a week on a heavily loaded system (I mean it). I did not ever experience filesystem corruption (related to the fs code). I did, however, hit complete system lockup once. It *may* have been unrelated to the fs code. (If you use quota, it *will* lock. The author is working on a fix. Above, I am referring to a lockup with quota off). Eugene -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Nicolas.Kowalski at imag.fr Wed Jun 16 18:34:47 2004 From: Nicolas.Kowalski at imag.fr (Nicolas Kowalski) Date: Wed, 16 Jun 2004 20:34:47 +0200 (MEST) Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <1087322976.1874.36.camel@pla.lokal.lan> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> Message-ID: On Tue, 15 Jun 2004, Petter Larsen wrote: > Hello Hello. > Wee need to have a very consistent and integrity for our filesystem, and > it would then be desired to journal both data and metadata. > > But if this mode can corrupt the filesystem as both Phil White and > Nicolas Kowalski has experienced, it may be more advised to use mode > data=ordered instead. In my case, the filesystem on this (old, so perhaps with disks beginning to fail) server was not corrupted. I only got some strange error messages, which went away when I switched back the data mode to ordered, as Phil White told me to try. Best regards. -- Nicolas From ext3 at philwhite.org Wed Jun 16 22:58:11 2004 From: ext3 at philwhite.org (Phil White) Date: Wed, 16 Jun 2004 15:58:11 -0700 (PDT) Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <40D06C0B.7020005@techsource.com> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <40D06C0B.7020005@techsource.com> Message-ID: <1805.216.148.213.196.1087426691.squirrel@www.code-visions.com> Petter, I was never able to resolve the problems I had with data=journal with the 2.4 kernel. I did *not* try the 2.6 kernel though, so I can't give you any data points there. In the end, I settled for data=ordered, and have never seen the problems I described in my original posts. Also, to give you some background, I had been using ReiserFS before switching to ext3, and I experienced a lot of corruption with Reiser (my company makes linux based appliances which sometimes get turned off while under heavy IO). Since ReiserFS doesn't do data journalling (metadata only), we consistently ended up with corrupt files. After this, I decided to try ext3 with data=journal, and I never even got far enough with load testing to try the 'hard reset' test. It would consistently crash in the fs code under heavy load. We have since had no problems with data=ordered, and since it writes data blocks before writing metadata to the journal, we don't see corrupt files anymore (even on hard resets). If data integrity (within the file) is important to you in the face of a crash or power loss, do NOT use ReiserFS or ext3 data=writeback. If your application never overwrites data in files, you will be just fine using data=ordered (appending to files or creating new files is pretty much guaranteed to never cause corruption). If you need to overwrite data in files, you need to use data=journal (and probably beg people to fix it) or rewrite your application to use some other method (i.e. copy the file, delete the old one) and just use data=ordered. --Phil > > > Petter Larsen wrote: > >> >> Data integrity is much more important for us than speed. >> > > > You might want to consider ReiserFS or one of the others which were > designed with journaling in mind. And I hope you're using RAID1 or RAID5. > > From pla at morecom.no Thu Jun 17 08:27:17 2004 From: pla at morecom.no (Petter Larsen) Date: Thu, 17 Jun 2004 10:27:17 +0200 Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <200406160734.i5G7YZwV002051@car.linuxhacker.ru> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <200406160734.i5G7YZwV002051@car.linuxhacker.ru> Message-ID: <1087460837.2765.31.camel@pla.lokal.lan> Hello I comment inline.. > PL> Can anybody of you acknowledge or not if mode data=journal in ext3 is > PL> safe to use in Linux kernel 2.6.x? > PL> Wee need to have a very consistent and integrity for our filesystem, and > PL> it would then be desired to journal both data and metadata. > > OLEG> Actually data=journal mode would gain you mostly zero extra consistency compared > to data=ordered mode. (the only more consistency bit that you get is > correct mtime on files that have their pages overwritten, I think). > You have zero control over transaction boundaries in ext3, so you still need > to design your applications in such a way that they have their own > sort of transactions (if this is needed). So your conclusion is that data=journal mode is useless if you do not want a correct mtime? It would be a littles sense in developing the data=journal mode if this is the only benefit, don't you think? >From the Linux/Documentation/filesystems/ext3.txt data=journal All data are committed into the journal prior to being written into the main file system. data=ordered (*) All data are forced directly out to the main file system prior to its metadata being committed to the journal. My problem is that ext3 in the latest kernel, 2.6.x and the latest 2.4.x, are not well documented around the web. Whitepapers and so are pretty old. Much have changed I belive in ext3 since it was first introduced by Dr. Tweedie. The first release was journaling both data and metadata, se also the transcript from Dr. Tweedie from the Ottawa Linux Symposium 20th July 2000. http://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html There he says that they are journaling both metadata and data, but that the design goal is not to do that. So can this be interpreted that mode data=journal is only there for historic reasons? > PL> Data integrity is much more important for us than speed. > > OLEG> It is not clear what sort of extra data integrity do you expect from data > journaling mode and why do you think it is there. I would belive that the goal for such a mode data=journal would gain extra data integrity because it also journals data. Why should it not? I would belive that it makes sense to have these different modes so people can choose the best mode for there applications. > OLEG> Garbage in files should not happen in data ordered mode as data pages are > written first before metadata updates are committed. Are you sure? Petter From pla at morecom.no Thu Jun 17 08:29:43 2004 From: pla at morecom.no (Petter Larsen) Date: Thu, 17 Jun 2004 10:29:43 +0200 Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <40D06C0B.7020005@techsource.com> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <40D06C0B.7020005@techsource.com> Message-ID: <1087460983.2765.34.camel@pla.lokal.lan> > > > > Data integrity is much more important for us than speed. > > > > > You might want to consider ReiserFS or one of the others which were > designed with journaling in mind. And I hope you're using RAID1 or RAID5. We are using ext3 on a compact flash disk in an embedded device. So we are not using RAID systems. Best regards -- Petter Larsen cand. scient. moreCom as 913 17 222 From pla at morecom.no Thu Jun 17 08:36:53 2004 From: pla at morecom.no (Petter Larsen) Date: Thu, 17 Jun 2004 10:36:53 +0200 Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <1087323602.16701.42.camel@ariel.sovam.com> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <1087323602.16701.42.camel@ariel.sovam.com> Message-ID: <1087461413.2765.42.camel@pla.lokal.lan> > > > > Data integrity is much more important for us than speed. > > I ran ext3 with data=journal on 2.6.6smp for about a week on a heavily > loaded system (I mean it). I did not ever experience filesystem > corruption (related to the fs code). I did, however, hit complete > system lockup once. It *may* have been unrelated to the fs code. > > (If you use quota, it *will* lock. The author is working on a fix. > Above, I am referring to a lockup with quota off). > > Eugene Good to here. But there may have been a lookup once because you are not sure that the crash was unrelated to ext3 fs code? Are you going to test it more? We are not going to use quota, we are using ext3 on a compact flash disk in an embedded device. -- Petter Larsen cand. scient. moreCom as 913 17 222 From pla at morecom.no Thu Jun 17 11:23:32 2004 From: pla at morecom.no (Petter Larsen) Date: Thu, 17 Jun 2004 13:23:32 +0200 Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <1805.216.148.213.196.1087426691.squirrel@www.code-visions.com> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <40D06C0B.7020005@techsource.com> <1805.216.148.213.196.1087426691.squirrel@www.code-visions.com> Message-ID: <1087471412.2765.209.camel@pla.lokal.lan> > I was never able to resolve the problems I had with data=journal with the > 2.4 kernel. I did *not* try the 2.6 kernel though, so I can't give you > any data points there. In the end, I settled for data=ordered, and have > never seen the problems I described in my original posts. Also, to give > you some background, I had been using ReiserFS before switching to ext3, > and I experienced a lot of corruption with Reiser (my company makes linux > based appliances which sometimes get turned off while under heavy IO). > Since ReiserFS doesn't do data journalling (metadata only), we > consistently ended up with corrupt files. After this, I decided to try > ext3 with data=journal, and I never even got far enough with load testing > to try the 'hard reset' test. It would consistently crash in the fs code > under heavy load. This should be considered a serious bug, dont you think. Have you reported this to the kernel list? I have the list now on the CC, but it probably should be made as a bug report. > > We have since had no problems with data=ordered, and since it writes data > blocks before writing metadata to the journal, we don't see corrupt files > anymore (even on hard resets). Ok > > If data integrity (within the file) is important to you in the face of a > crash or power loss, do NOT use ReiserFS or ext3 data=writeback. If your > application never overwrites data in files, you will be just fine using > data=ordered (appending to files or creating new files is pretty much > guaranteed to never cause corruption). If you need to overwrite data in > files, you need to use data=journal (and probably beg people to fix it) or > rewrite your application to use some other method (i.e. copy the file, > delete the old one) and just use data=ordered. > So data=journal would gain safer data integrity (if it works as intended then) than using data=ordered. But if data=journal does not work correctly we may be better off using data=ordered if we design our application after it. The problem is that we can not do this consistent because we have a mix of both open source applications and our own developed applications. But think of your scenario of copy, delete and make a new file with the new content. First we copy the contents of the file, then we do our modifications. When we are done we delete the original file. Then we hit a crash. The content we had of the file in our process are gone, the original file is deleted. This is not a good idea. But if we write the new file first as fileX.new and den delete fileX, hit a crash then we would have at least the correct file written as fileX.new. But we would be best off if we could trust the filesystem. In practise there are probably many more systems out there which use data=ordered because this is the default, and therefor get best testet. Journaling both data and metadata was what Dr. Tweedie did in the first public releases, but the goal was not to do it. It is not easy to know what is the best thing to do. We use this ext3 filesystem on a compact flash in an embedded system. Petter From adilger at clusterfs.com Thu Jun 17 16:26:56 2004 From: adilger at clusterfs.com (Andreas Dilger) Date: Thu, 17 Jun 2004 10:26:56 -0600 Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <1087471412.2765.209.camel@pla.lokal.lan> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <40D06C0B.7020005@techsource.com> <1805.216.148.213.196.1087426691.squirrel@www.code-visions.com> <1087471412.2765.209.camel@pla.lokal.lan> Message-ID: <20040617162656.GB14915@schnapps.adilger.int> On Jun 17, 2004 13:23 +0200, Petter Larsen wrote: > But think of your scenario of copy, delete and make a new file with the > new content. First we copy the contents of the file, then we do our > modifications. When we are done we delete the original file. Then we hit > a crash. The content we had of the file in our process are gone, the > original file is deleted. This is not a good idea. But if we write the new > file first as fileX.new and den delete fileX, hit a crash then we would > have at least the correct file written as fileX.new. The rename operation is guaranteed to be atomic. You implement updates as: 1) create new file 2) write data to new file 3) rename new file over old filename If the system crashes at any time you are guaranteed that the old filename has valid data in it. Even if you use data=journal mode while overwriting the old filename directly you wouldn't be guaranteed to have valid data unless your application was only e.g. writing aligned records to fixed file offsets, and those records were <= 4kB in size. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rnice at nicey.com Sat Jun 19 11:14:10 2004 From: rnice at nicey.com (Robert Nice) Date: Sat, 19 Jun 2004 07:14:10 -0400 Subject: Oops in journal_dirty_sync_data [ext3] Message-ID: <40D42002.1050605@nicey.com> Hi all, This just got me out of bed at 5am. Although there are a lot of Oops reports on the list I didn't find any for my kernel version or with a similar stack trace. I'm wondering if this is a known issue? Kernel: 2.4.20-8 (Redhat 9.0 default kernel). There's 2GB of RAM, I'm using barely 1/4 of it. I'm fairly confident RAM is okay (memchecked on install). Disk is supposed to be RAID 5, there are no other indications of disk problems. The java app in question has a _lot_ of threads which can do disk writes. The java process locked up and wouldn't even die with a kill -9. Required a reboot to clear it out. This is the first time this has happened, box is around 3 months old with pretty good reliability so far. I see there's a newer kernel (2.4.20-31.9) on the RH update server, but before I just upgrade and hope for the best I thought I'd post. Thanks in advance, --- Jun 19 09:43:25 ldu506 kernel: Unable to handle kernel paging request at virtual address 0000d050 Jun 19 09:43:25 ldu506 kernel: printing eip: Jun 19 09:43:25 ldu506 kernel: c0118d40 Jun 19 09:43:25 ldu506 kernel: *pde = 00000000 Jun 19 09:43:25 ldu506 kernel: Oops: 0000 Jun 19 09:43:25 ldu506 kernel: autofs 8139too mii sis900 keybdev mousedev hid input ehci-hcd usb-ohci usbcore ext3 jbd aic7xxx sd_mod scsi_mod Jun 19 09:43:25 ldu506 kernel: CPU: 0 Jun 19 09:43:25 ldu506 kernel: EIP: 0060:[] Not tainted Jun 19 09:43:25 ldu506 kernel: EFLAGS: 00010007 Jun 19 09:43:25 ldu506 kernel: Jun 19 09:43:25 ldu506 kernel: EIP is at __wake_up [kernel] 0x20 (2.4.20-8) Jun 19 09:43:25 ldu506 kernel: eax: c030db54 ebx: 0000d054 ecx: 00000001 edx: 00000003 Jun 19 09:43:25 ldu506 kernel: esi: c030db54 edi: 00000003 ebp: f5e5df00 esp: f5e5dee0 Jun 19 09:43:26 ldu506 kernel: ds: 0068 es: 0068 ss: 0068 Jun 19 09:43:26 ldu506 kernel: Process java (pid: 11287, stackpage=f5e5d000) Jun 19 09:43:26 ldu506 kernel: Stack: 00000000 f8866d60 00000000 00000001 00000282 00000000 c277aa90 fe38012e Jun 19 09:43:26 ldu506 kernel: 79ebab9b c01364f5 d3d89380 c277aa90 0000011b 0000012e 084291c4 c012c0de Jun 19 09:43:26 ldu506 kernel: ffffffff 00000000 0000012e f7b35c2c c277aa90 00000000 0000011b d4327cec Jun 19 09:43:26 ldu506 kernel: Call Trace: [] journal_dirty_sync_data [ext3] 0x0 (0xf5e5dee4)) Jun 19 09:43:26 ldu506 kernel: [] generic_file_write [kernel] 0x5d5 (0xf5e5df04)) Jun 19 09:43:26 ldu506 kernel: [] futex_wait [kernel] 0x10e (0xf5e5df1c)) Jun 19 09:43:26 ldu506 kernel: [] ext3_file_write [ext3] 0x39 (0xf5e5df74)) Jun 19 09:43:26 ldu506 kernel: [] sys_write [kernel] 0xa3 (0xf5e5df94)) Jun 19 09:43:26 ldu506 kernel: [] system_call [kernel] 0x33 (0xf5e5dfc0)) Jun 19 09:43:26 ldu506 kernel: Jun 19 09:43:26 ldu506 kernel: Jun 19 09:43:26 ldu506 kernel: Code: 8b 53 fc 8b 02 85 c7 75 17 8b 1b 39 f3 75 f1 ff 75 f0 9d 83 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pla at morecom.no Mon Jun 21 17:42:28 2004 From: pla at morecom.no (Petter Larsen) Date: Mon, 21 Jun 2004 19:42:28 +0200 Subject: mode data=journal in ext3. Is it safe to use? Conclusion In-Reply-To: <20040618120513.GA2394@linuxhacker.ru> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <200406160734.i5G7YZwV002051@car.linuxhacker.ru> <1087460837.2765.31.camel@pla.lokal.lan> <20040617170939.GO2659@linuxhacker.ru> <40D2B8C3.8090908@hist.no> <20040618101520.GA2389@linuxhacker.ru> <1087558255.25904.14.camel@pmarqueslinux> <20040618120513.GA2394@linuxhacker.ru> Message-ID: <1087839748.6288.165.camel@pla.lokal.lan> I will summarise this thread and try to set the picture of what has been discussed and concluded. 1. ext3 with mode data=journal in kernel 2.6.x is probably working as intended. One has responded with using this mode heavily on 2.6.6 without corruption related to the fs code. Since nobody has said that they have seen faults, we should belive that it is safe. It is in an stable kernel... 2. Mode data=journal will not gain much more than correct mtime compared to mode data=ordered. 3. Applications that need a very consistent filesystem, e.g. consistent writes, they need to do this by implementing there own transaction/journaling system. Alberto Bertogli has written a library that can assist with this. See URL, http://users.auriga.wearlab.de/~alb/libjio/. I have not used it so I can not say for sure how good it is, but it seems like a nice start and worth to take a look at. 4. Because mode data=journal does not gain much, it would be better to use mode data=ordered and use any form of transaction/journaling itself. Mode data=ordered is the default in ext3 and probably most used, and therefor also best tested. 5. If, and only if, you have less than 1 block size updates (that do not cross block boundaries), these operations (write) can be done atomically. (with help of fsync and stuff,(from Oleg and others)). 6. Wear leveling on a Compact Flash card: Wear leveling is an important task. SanDisk has Industrial Grade support for some of there CF-cards, see these links. http://www.sandisk.com/pressrelease/020522_toughness.htm http://www.sandisk.com/pressrelease/021112_igapps.htm http://www.sandisk.com/pdf/oem/WPaperWearLevelv1.0.pdf We are in the telecommunications and networking business and need this kind of Compact Flash cards. From there site: * Enhanced error correction and sophisticated wear leveling technology * Card level MTBF >3 million hours * 2 million program/erase cycle endurance per block We are not bound to SanDisk. We could use any suplier that meet these criteria. I do not know the wear leveling algorithm in detail so how they shuffle read-only data (or if they do) around the disk, and even how it does it if we create partitions on this CF disk (partition are probably transparent for the wear leveling algorithm), is an issue we need to find out of. Thanks for all your replies ( there are 32 threads:-) spread along the ext3 ML and the LKML and a couple private ). It has helped me a lot. Best regards -- Petter Larsen cand. scient. moreCom as 913 17 222 From miller at techsource.com Wed Jun 16 15:49:31 2004 From: miller at techsource.com (Timothy Miller) Date: Wed, 16 Jun 2004 11:49:31 -0400 Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <1087322976.1874.36.camel@pla.lokal.lan> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> Message-ID: <40D06C0B.7020005@techsource.com> Petter Larsen wrote: > > Data integrity is much more important for us than speed. > You might want to consider ReiserFS or one of the others which were designed with journaling in mind. And I hope you're using RAID1 or RAID5. From davej at redhat.com Thu Jun 17 10:08:14 2004 From: davej at redhat.com (Dave Jones) Date: Thu, 17 Jun 2004 11:08:14 +0100 Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <40D12DB6.3080606@namesys.com> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <40D06C0B.7020005@techsource.com> <871xkfroph.fsf@enki.rimspace.net> <40D12DB6.3080606@namesys.com> Message-ID: <20040617100813.GA19280@redhat.com> On Wed, Jun 16, 2004 at 10:35:50PM -0700, Hans Reiser wrote: > >the reluctance of the developers to adapt to the 4K kernel stacks in > >2.6.recent, > > > do you use them? I don't know real users who do, or else I would be > quicker to care. The Fedora Core 2 kernel (and what will be RHEL4) is currently using 4K stacks. This makes up quite a large userbase. > On the one hand, you complain about how we were unstable, and on the > other hand you complain about how we aren't willing to destabilize the > code to add new features to what is no longer the development branch. > Seems pretty inconsistent logically to me. If you really are reluctant it fix it, there's always the option of marking CONFIG_REISER4 as dependant on CONFIG_BROKEN if CONFIG_4KSTACKS is selected. Dave From daniel at rimspace.net Thu Jun 17 00:51:54 2004 From: daniel at rimspace.net (Daniel Pittman) Date: Thu, 17 Jun 2004 10:51:54 +1000 Subject: mode data=journal in ext3. Is it safe to use? References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <40D06C0B.7020005@techsource.com> Message-ID: <871xkfroph.fsf@enki.rimspace.net> On 17 Jun 2004, Timothy Miller wrote: > Petter Larsen wrote: > >> Data integrity is much more important for us than speed. > > You might want to consider ReiserFS or one of the others which were > designed with journaling in mind. And I hope you're using RAID1 or > RAID5. I must admit, that isn't quite the response that I would have expected for those requirements. :) ReiserFS, XFS and (presumably) JFS all have considerably better performance than ext3, for most tasks, because they were indeed designed with journaling in mind. OTOH, ReiserFS had an extremely long period of instability, and was build by a group who felt that a working fsck was something you put together after you got the filesystem working. This, combined with the occasional "ReiserFS 3 ate my data" reports and the reluctance of the developers to adapt to the 4K kernel stacks in 2.6.recent, would leave me hesitant to recommend it as "more trustworthy" than ext3. XFS, with the "null out data on recovery" mode, is less reliable than ext3, full stop. It routinely destroys data in real world situations, a secure, but irritating, choice. ext3 remains the only journaling filesystem that I would, personally, put any great degree of faith in, since it is still developed in a cautious and safe fashion, and has a focus on getting the tools to verify correctness in place before enabling kernel-side features. Obviously, your millage may vary on these topics, as presumably have your experiences. Regards, Daniel -- Advertising may be described as the science of arresting the human intelligence long enough to get money from it. -- Stephen Leacock From reiser at namesys.com Thu Jun 17 05:35:50 2004 From: reiser at namesys.com (Hans Reiser) Date: Wed, 16 Jun 2004 22:35:50 -0700 Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <871xkfroph.fsf@enki.rimspace.net> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <40D06C0B.7020005@techsource.com> <871xkfroph.fsf@enki.rimspace.net> Message-ID: <40D12DB6.3080606@namesys.com> Daniel Pittman wrote: >OTOH, ReiserFS had an extremely long period of instability, > we were stable before ext3 was... >and was >build by a group who felt that a working fsck was something you put >together after you got the filesystem working. > > Well, if you have a total of two guys working on a filesystem, and plenty not working yet in the filesystem, why the hell would you start to work on fsck before the main body of code is working and performing well enough that anybody would want to use it? Surely my task ordering was correct for a two man team. With Reiser4 we had funding for an fsck guy, and as a result fsck is working at ship. With V3, we had no funding at all until it started to work. >This, combined with the occasional "ReiserFS 3 ate my data" reports and > > like ext2/ext3, we are now able to say that almost all such reports are hardware (for V3 not V4, V4 gained some bugs when we ported to -mm and its radix trees, and is still not shipped as a result). >the reluctance of the developers to adapt to the 4K kernel stacks in >2.6.recent, > do you use them? I don't know real users who do, or else I would be quicker to care. On the one hand, you complain about how we were unstable, and on the other hand you complain about how we aren't willing to destabilize the code to add new features to what is no longer the development branch. Seems pretty inconsistent logically to me. From daniel at rimspace.net Thu Jun 17 09:15:57 2004 From: daniel at rimspace.net (Daniel Pittman) Date: Thu, 17 Jun 2004 19:15:57 +1000 Subject: mode data=journal in ext3. Is it safe to use? References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <40D06C0B.7020005@techsource.com> <1087460983.2765.34.camel@pla.lokal.lan> Message-ID: <87wu26mto2.fsf@enki.rimspace.net> On 17 Jun 2004, Petter Larsen wrote: >>> >>> Data integrity is much more important for us than speed. >> >> You might want to consider ReiserFS or one of the others which were >> designed with journaling in mind. And I hope you're using RAID1 or RAID5. > > We are using ext3 on a compact flash disk in an embedded device. So we > are not using RAID systems. Watch out - even with the internal wear leveling the CF disk will do, ext3 is still a pretty heavy filesystem to use there. Daniel -- The great end of life is not knowledge, but action. What men need is as much knowledge as they can organize for action; give them more and it may become injurious. Some men are heavy and stupid from undigested learning. -- Thomas Henry Huxley From reiser at namesys.com Thu Jun 17 16:55:43 2004 From: reiser at namesys.com (Hans Reiser) Date: Thu, 17 Jun 2004 09:55:43 -0700 Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <20040617100813.GA19280@redhat.com> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <40D06C0B.7020005@techsource.com> <871xkfroph.fsf@enki.rimspace.net> <40D12DB6.3080606@namesys.com> <20040617100813.GA19280@redhat.com> Message-ID: <40D1CD0F.4030306@namesys.com> Dave Jones wrote: >On Wed, Jun 16, 2004 at 10:35:50PM -0700, Hans Reiser wrote: > > > >the reluctance of the developers to adapt to the 4K kernel stacks in > > >2.6.recent, > > > > > do you use them? I don't know real users who do, or else I would be > > quicker to care. > >The Fedora Core 2 kernel (and what will be RHEL4) is currently >using 4K stacks. This makes up quite a large userbase. > > Sigh. I guess we have to support it then. Chris, are you up to doing it? > > On the one hand, you complain about how we were unstable, and on the > > other hand you complain about how we aren't willing to destabilize the > > code to add new features to what is no longer the development branch. > > Seems pretty inconsistent logically to me. > >If you really are reluctant it fix it, there's always the option of >marking CONFIG_REISER4 as dependant on CONFIG_BROKEN if CONFIG_4KSTACKS >is selected. > > Dave > > > > > From green at linuxhacker.ru Thu Jun 17 17:09:39 2004 From: green at linuxhacker.ru (Oleg Drokin) Date: Thu, 17 Jun 2004 20:09:39 +0300 Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <1087460837.2765.31.camel@pla.lokal.lan> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <200406160734.i5G7YZwV002051@car.linuxhacker.ru> <1087460837.2765.31.camel@pla.lokal.lan> Message-ID: <20040617170939.GO2659@linuxhacker.ru> Hello! On Thu, Jun 17, 2004 at 10:27:17AM +0200, Petter Larsen wrote: > > PL> Can anybody of you acknowledge or not if mode data=journal in ext3 is > > PL> safe to use in Linux kernel 2.6.x? > > PL> Wee need to have a very consistent and integrity for our filesystem, and > > PL> it would then be desired to journal both data and metadata. > > OLEG> Actually data=journal mode would gain you mostly zero extra consistency compared > > to data=ordered mode. (the only more consistency bit that you get is > > correct mtime on files that have their pages overwritten, I think). > > You have zero control over transaction boundaries in ext3, so you still need > > to design your applications in such a way that they have their own > > sort of transactions (if this is needed). > So your conclusion is that data=journal mode is useless if you do not > want a correct mtime? Well, yes. > It would be a littles sense in developing the data=journal mode if this > is the only benefit, don't you think? > >From the Linux/Documentation/filesystems/ext3.txt > data=journal All data are committed into the journal prior > to being written into the main file system. > data=ordered (*) All data are forced directly out to the main > file system prior to its metadata being committed to > the journal. > My problem is that ext3 in the latest kernel, 2.6.x and the latest > 2.4.x, are not well documented around the web. Whitepapers and so are > pretty old. Much have changed I belive in ext3 since it was first > introduced by Dr. Tweedie. The first release was journaling both data > and metadata, se also the transcript from Dr. Tweedie from the Ottawa > Linux Symposium 20th July 2000. > http://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html > There he says that they are journaling both metadata and data, but that > the design goal is not to do that. So can this be interpreted that mode > data=journal is only there for historic reasons? May be so. Also fsync heavy loads on real disk devices with large journals tend to benefit from journaled data mode as well. > > PL> Data integrity is much more important for us than speed. > > > > OLEG> It is not clear what sort of extra data integrity do you expect from data > > journaling mode and why do you think it is there. > I would belive that the goal for such a mode data=journal would gain > extra data integrity because it also journals data. Why should it not? I Well, actually I bet you do not care if the data goes through journal or not as long as it is not lost. In case of ordered journaling mode, data is written first before metadata updates, mostly the same happens with data journal mode, only with the latter case date is written into journal and if transaction was not committed, after a reboot it won't be copied to where it should be, same scenario in ordered journal mode will result in data getting where it should be, but due to lack of metadata updates, you won't see it. (this is in case of append, for overwrite it will be a little bit different, but still you have no control over how much of stuff will be overwritten). > would belive that it makes sense to have these different modes so people > can choose the best mode for there applications. True. > > OLEG> Garbage in files should not happen in data ordered mode as data pages are > > written first before metadata updates are committed. > Are you sure? If you can reproduce a garbage in files in ordered journal mode, that would be a bug that should be fixed then. Bye, Oleg From degger at fhm.edu Thu Jun 17 19:30:05 2004 From: degger at fhm.edu (Daniel Egger) Date: Thu, 17 Jun 2004 21:30:05 +0200 Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <1087460983.2765.34.camel@pla.lokal.lan> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <40D06C0B.7020005@techsource.com> <1087460983.2765.34.camel@pla.lokal.lan> Message-ID: On 17.06.2004, at 10:29, Petter Larsen wrote: > We are using ext3 on a compact flash disk in an embedded device. So we > are not using RAID systems. An excellent way to kill such media. Hopefully YMMV. Servus, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 478 bytes Desc: This is a digitally signed message part URL: From daniel at rimspace.net Fri Jun 18 02:56:56 2004 From: daniel at rimspace.net (Daniel Pittman) Date: Fri, 18 Jun 2004 12:56:56 +1000 Subject: mode data=journal in ext3. Is it safe to use? References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <40D06C0B.7020005@techsource.com> <1805.216.148.213.196.1087426691.squirrel@www.code-visions.com> <1087471412.2765.209.camel@pla.lokal.lan> <20040617162656.GB14915@schnapps.adilger.int> Message-ID: <87wu25k1zb.fsf@enki.rimspace.net> On 18 Jun 2004, Andreas Dilger wrote: > On Jun 17, 2004 13:23 +0200, Petter Larsen wrote: >> But think of your scenario of copy, delete and make a new file with the >> new content. First we copy the contents of the file, then we do our >> modifications. When we are done we delete the original file. Then we hit >> a crash. The content we had of the file in our process are gone, the >> original file is deleted. This is not a good idea. But if we write the new >> file first as fileX.new and den delete fileX, hit a crash then we would >> have at least the correct file written as fileX.new. > > The rename operation is guaranteed to be atomic. You implement updates as: > 1) create new file > 2) write data to new file > 3) rename new file over old filename Step three in this chain has always puzzled me: is there some "atomic rename" that I have missed, or is this really: 3) unlink (or rename away) old filename 4) rename new filename to old filename Daniel -- I refused to attend his funeral. But I wrote a very nice letter explaining that I approved of it. -- Mark Twain From helge.hafting at hist.no Fri Jun 18 09:41:23 2004 From: helge.hafting at hist.no (Helge Hafting) Date: Fri, 18 Jun 2004 11:41:23 +0200 Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <20040617170939.GO2659@linuxhacker.ru> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <200406160734.i5G7YZwV002051@car.linuxhacker.ru> <1087460837.2765.31.camel@pla.lokal.lan> <20040617170939.GO2659@linuxhacker.ru> Message-ID: <40D2B8C3.8090908@hist.no> Oleg Drokin wrote: >Hello! > >On Thu, Jun 17, 2004 at 10:27:17AM +0200, Petter Larsen wrote: > > >>>PL> Can anybody of you acknowledge or not if mode data=journal in ext3 is >>>PL> safe to use in Linux kernel 2.6.x? >>>PL> Wee need to have a very consistent and integrity for our filesystem, and >>>PL> it would then be desired to journal both data and metadata. >>>OLEG> Actually data=journal mode would gain you mostly zero extra consistency compared >>>to data=ordered mode. (the only more consistency bit that you get is >>>correct mtime on files that have their pages overwritten, I think). >>>You have zero control over transaction boundaries in ext3, so you still need >>>to design your applications in such a way that they have their own >>>sort of transactions (if this is needed). >>> >>> >>So your conclusion is that data=journal mode is useless if you do not >>want a correct mtime? >> >> > >Well, yes. > > > >>It would be a littles sense in developing the data=journal mode if this >>is the only benefit, don't you think? >>>From the Linux/Documentation/filesystems/ext3.txt >>data=journal All data are committed into the journal prior >> to being written into the main file system. >>data=ordered (*) All data are forced directly out to the main >>file system prior to its metadata being committed to >> the journal. >>My problem is that ext3 in the latest kernel, 2.6.x and the latest >>2.4.x, are not well documented around the web. Whitepapers and so are >>pretty old. Much have changed I belive in ext3 since it was first >>introduced by Dr. Tweedie. The first release was journaling both data >>and metadata, se also the transcript from Dr. Tweedie from the Ottawa >>Linux Symposium 20th July 2000. >>http://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html >>There he says that they are journaling both metadata and data, but that >>the design goal is not to do that. So can this be interpreted that mode >>data=journal is only there for historic reasons? >> >> > >May be so. Also fsync heavy loads on real disk devices with large journals >tend to benefit from journaled data mode as well. > > > >>>PL> Data integrity is much more important for us than speed. >>> >>>OLEG> It is not clear what sort of extra data integrity do you expect from data >>>journaling mode and why do you think it is there. >>> >>> >>I would belive that the goal for such a mode data=journal would gain >>extra data integrity because it also journals data. Why should it not? I >> >> > >Well, actually I bet you do not care if the data goes through journal or not >as long as it is not lost. >In case of ordered journaling mode, data is written first before metadata >updates, mostly the same happens with data journal mode, only with the latter >case date is written into journal and if transaction was not committed, after >a reboot it won't be copied to where it should be, same scenario in ordered >journal mode will result in data getting where it should be, but due to >lack of metadata updates, you won't see it. (this is in case of append, >for overwrite it will be a little bit different, but still you have no >control over how much of stuff will be overwritten). > > > >>would belive that it makes sense to have these different modes so people >>can choose the best mode for there applications. >> >> > >True. > > > >>>OLEG> Garbage in files should not happen in data ordered mode as data pages are >>>written first before metadata updates are committed. >>> >>> >>Are you sure? >> >> > >If you can reproduce a garbage in files in ordered journal mode, that would be a >bug that should be fixed then. > > Hard to _produce_, but consider: 1. Write data to an existing file 2. Sync metadata 3. data is forced out because of ordered mode, a powerout crash happens in the middle of this. The file now has a block with a mix of new and old, it may even be unreadable due to a bad sector checksum. With data journalling you either get the old data (because the crash happened during a write to the journal) or new data (crash happened during data write, the data is restored from the good copy in the journal.) Helge Hafting From green at linuxhacker.ru Fri Jun 18 10:15:20 2004 From: green at linuxhacker.ru (Oleg Drokin) Date: Fri, 18 Jun 2004 13:15:20 +0300 Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <40D2B8C3.8090908@hist.no> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <200406160734.i5G7YZwV002051@car.linuxhacker.ru> <1087460837.2765.31.camel@pla.lokal.lan> <20040617170939.GO2659@linuxhacker.ru> <40D2B8C3.8090908@hist.no> Message-ID: <20040618101520.GA2389@linuxhacker.ru> Hello! On Fri, Jun 18, 2004 at 11:41:23AM +0200, Helge Hafting wrote: > >If you can reproduce a garbage in files in ordered journal mode, that > >would be a > >bug that should be fixed then. > Hard to _produce_, but consider: > 1. Write data to an existing file > 2. Sync metadata > 3. data is forced out because of ordered mode, a powerout crash happens > in the middle of this. The file now has a block with a mix of new > and old, Well, this is not much worse than having two blocks, one from old file and one from new after a crash. > it may even be unreadable due to a bad sector checksum. Well, in data journaled mode you may get unreadable journal, is this much better? (Also original question was about CF flash media, so no bad sector problems I presume). > With data journalling you either get the old data (because the crash > happened > during a write to the journal) or new data (crash happened during data > write, Well, while with data journaling mode your granularity is one block, with data ordered it is one sector. > the data is restored from the good copy in the journal.) Bye, Oleg From pmarques at grupopie.com Fri Jun 18 11:30:55 2004 From: pmarques at grupopie.com (Paulo Marques) Date: Fri, 18 Jun 2004 12:30:55 +0100 Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <20040618101520.GA2389@linuxhacker.ru> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <200406160734.i5G7YZwV002051@car.linuxhacker.ru> <1087460837.2765.31.camel@pla.lokal.lan> <20040617170939.GO2659@linuxhacker.ru> <40D2B8C3.8090908@hist.no> <20040618101520.GA2389@linuxhacker.ru> Message-ID: <1087558255.25904.14.camel@pmarqueslinux> On Fri, 2004-06-18 at 11:15, Oleg Drokin wrote: > Hello! > > On Fri, Jun 18, 2004 at 11:41:23AM +0200, Helge Hafting wrote: > > > >If you can reproduce a garbage in files in ordered journal mode, that > > >would be a > > >bug that should be fixed then. > > Hard to _produce_, but consider: > > 1. Write data to an existing file > > 2. Sync metadata > > 3. data is forced out because of ordered mode, a powerout crash happens > > in the middle of this. The file now has a block with a mix of new > > and old, > > Well, this is not much worse than having two blocks, one from old file > and one from new after a crash. Agree. If the application needs consistency it must do some journaling itself. At least, until the time when an application can say "start transaction" "commit transaction" to the file system itself. > > it may even be unreadable due to a bad sector checksum. > > Well, in data journaled mode you may get unreadable journal, is this much > better? (Also original question was about CF flash media, so no bad sector > problems I presume). You got it wrong here. The sentence was "bad sector checksum", not "bad sector". If the sector was "half written", then the checksum would not match. If the journal is "half written" then it is just discarded (or at least it should be). > > With data journalling you either get the old data (because the crash > > happened > > during a write to the journal) or new data (crash happened during data > > write, > > Well, while with data journaling mode your granularity is one block, > with data ordered it is one sector. Imagine that you request a 2Mb write to an ext3 filesystem with an 1Mb journal. There is *no way* the filesystem can do the write in an atomic operation. (there would be if the filesystem wrote the data to free blocks and updated the metadata through the journal) The point is, there is no concept of "atomic operation" at the file system level, so the application must do journaling itself if it wants to have some concept of "transactions". >From my experience with CF cards, there are some brands that do wear-leveling (I know that at least the TwinMOS ones do, and probably SanDisk too) and others that don't (Kingmax). With a bad CF card and an ext3 filesystem you can get bad sectors in a couple of hours doing some intensive writing. A good CF card will sustain "normal use" (2 writes per minute average) and an ext3 filesystem for months (maybe years, I still didn't went that far in time :) Just my two cents, -- Paulo Marques - www.grupopie.com "In a world without walls and fences who needs windows and gates?" From green at linuxhacker.ru Fri Jun 18 12:05:14 2004 From: green at linuxhacker.ru (Oleg Drokin) Date: Fri, 18 Jun 2004 15:05:14 +0300 Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <1087558255.25904.14.camel@pmarqueslinux> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <200406160734.i5G7YZwV002051@car.linuxhacker.ru> <1087460837.2765.31.camel@pla.lokal.lan> <20040617170939.GO2659@linuxhacker.ru> <40D2B8C3.8090908@hist.no> <20040618101520.GA2389@linuxhacker.ru> <1087558255.25904.14.camel@pmarqueslinux> Message-ID: <20040618120513.GA2394@linuxhacker.ru> Hello! On Fri, Jun 18, 2004 at 12:30:55PM +0100, Paulo Marques wrote: > > > Hard to _produce_, but consider: > > > 1. Write data to an existing file > > > 2. Sync metadata > > > 3. data is forced out because of ordered mode, a powerout crash happens > > > in the middle of this. The file now has a block with a mix of new > > > and old, > > Well, this is not much worse than having two blocks, one from old file > > and one from new after a crash. > Agree. If the application needs consistency it must do some journaling > itself. At least, until the time when an application can say "start > transaction" "commit transaction" to the file system itself. Right, this is my point. > > > it may even be unreadable due to a bad sector checksum. > > Well, in data journaled mode you may get unreadable journal, is this much > > better? (Also original question was about CF flash media, so no bad sector > > problems I presume). > You got it wrong here. The sentence was "bad sector checksum", not "bad > sector". If the sector was "half written", then the checksum would not > match. In any case bad sector checksum is hardware bug. Sector write is supposed to be atomic, it either happens or not. > If the journal is "half written" then it is just discarded (or at least > it should be). Well, if there is bad sector checksum inside journal block, ext3 won't be all that happy about this for sure (and most of other journaling filesystems as well, I am sure). > > > With data journalling you either get the old data (because the crash > > > happened > > > during a write to the journal) or new data (crash happened during data > > > write, > > Well, while with data journaling mode your granularity is one block, > > with data ordered it is one sector. > Imagine that you request a 2Mb write to an ext3 filesystem with an 1Mb > journal. There is *no way* the filesystem can do the write in an atomic > operation. (there would be if the filesystem wrote the data to free > blocks and updated the metadata through the journal) True. Even if you write 512K of data and have 1Mb journal, still there is no atomicity guarantee. > The point is, there is no concept of "atomic operation" at the file > system level, so the application must do journaling itself if it wants > to have some concept of "transactions". Well, if you go with less than 1 block size updates (that do not cross block boundaries), this can be done atomically. (with help of fsync and stuff). > >From my experience with CF cards, there are some brands that do > wear-leveling (I know that at least the TwinMOS ones do, and probably > SanDisk too) and others that don't (Kingmax). > With a bad CF card and an ext3 filesystem you can get bad sectors in a > couple of hours doing some intensive writing. Well, for flash memory there is jffs2, it does (data) journalling and supports compression. And it can even work over conventional block devices via mtd block emulation, I think. Basically jffs2 is one large fs-sized journal as I understand it. Bye, Oleg From yeung3m at yahoo.com Sun Jun 20 14:41:51 2004 From: yeung3m at yahoo.com (Kim Yeung) Date: Sun, 20 Jun 2004 22:41:51 +0800 Subject: Redhat 9 hang with quota problem Message-ID: <1087742511.40d5a22fd9e20@www.aerocreative.com> Hi, I'm running redhat 9 (kernel 2.4.20-8) as a heavy file server using ext3 file system. The server hang once a week and I found the following my log in /var/log/messages It looks like some ext3 quota problem. Anyone has similar experience ? Any suggestion ? Unable to handle kernel paging request at virtual address ffffffff printing eip: ffffffff *pde = 00001067 *pte = 00000000 Oops: 0000 iptable_filter ip_tables e100 keybdev mousedev hid input usb-uhci ehci-hcd usbcore ext3 jbd FastTrak sd_mod scsi_mod CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010202 EIP is at __insmod_iptable_filter_S.data_L876 [iptable_filter] 0x77089ff (2.4.20-8) eax: c039f020 ebx: ffffffff ecx: 00000007 edx: f4145000 esi: 00000012 edi: c039f028 ebp: 00000000 esp: db5c7c3c ds: 0068 es: 0068 ss: 0068 Process cp (pid: 25738, stackpage=db5c7000) Stack: c011c7df f4145000 00000000 c039f020 00000007 db5c6000 c997dd00 c0163a42 f4145000 c039f020 04000000 00000000 00000000 00001000 00000000 c01642a0 c997dd00 00000004 00000000 00000000 db5c7c96 00000001 00042330 c997dd00 Call Trace: [] tty_write_message [kernel] 0x4f (0xdb5c7c3c)) [] print_warning [kernel] 0x82 (0xdb5c7c58)) [] dquot_alloc_space [kernel] 0x140 (0xdb5c7c78)) [] ext3_new_block [ext3] 0xa30 (0xdb5c7cb0)) [] journal_dirty_metadata_R99e24994 [jbd] 0x17b (0xdb5c7cc8)) [] ext3_do_update_inode [ext3] 0x177 (0xdb5c7cf4)) [] journal_get_write_access_R095909b6 [jbd] 0x55 (0xdb5c7d14)) [] ext3_reserve_inode_write [ext3] 0x75 (0xdb5c7d34)) [] ext3_mark_iloc_dirty [ext3] 0x42 (0xdb5c7d50)) [] ext3_alloc_block [ext3] 0x37 (0xdb5c7d64)) [] ext3_alloc_branch [ext3] 0x50 (0xdb5c7d80)) [] journal_dirty_metadata_R99e24994 [jbd] 0x17b (0xdb5c7da8)) [] do_get_write_access [jbd] 0x2b4 (0xdb5c7dc0)) [] ext3_get_block_handle [ext3] 0x135 (0xdb5c7dd8)) [] ext3_do_update_inode [ext3] 0x177 (0xdb5c7e34)) [] create_buffers [kernel] 0x6b (0xdb5c7e38)) [] ext3_get_block [ext3] 0x4a (0xdb5c7e50)) [] __block_prepare_write [kernel] 0x193 (0xdb5c7e70)) [] block_prepare_write [kernel] 0x39 (0xdb5c7eb4)) [] ext3_get_block [ext3] 0x0 (0xdb5c7ec8)) [] ext3_prepare_write [ext3] 0xa3 (0xdb5c7ed4)) [] ext3_get_block [ext3] 0x0 (0xdb5c7ee4)) [] generic_file_write [kernel] 0x44d (0xdb5c7f04)) [] ext3_file_write [ext3] 0x39 (0xdb5c7f74)) [] sys_write [kernel] 0xa3 (0xdb5c7f94)) [] system_call [kernel] 0x33 (0xdb5c7fc0)) Code: Bad EIP value. Thanks Kim ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From jdolan at claritytel.com Tue Jun 22 15:53:14 2004 From: jdolan at claritytel.com (Jeremy Dolan) Date: Tue, 22 Jun 2004 10:53:14 -0500 Subject: ide/ext3 errors on two identical machines Message-ID: <20040622155314.GA5970@foozle> Wondering if anyone here might better be able to diagnose an issue we're seeing, or point me to some guidelines for this sort of thing. There are two machines with identical hardware, both running Red Hat 7.3's stock SMP kernel (required due to third party software). Both have come down with the same symptoms after having run fine for a number of months. The initial errors were these: kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } kernel: hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=54666719, high=3, low=4335071, sector=61720 kernel: end_request: I/O error, dev 03:09 (hda), sector 61720 kernel: journal_bmap_Rsmp_41b34d97: journal block not found at offset 7180 on ide0(3,9) kernel: Aborting journal on device ide0(3,9). kernel: ext3_reserve_inode_write: aborting transaction: Journal has aborted in __ext3_journal_get_write_access<2>EXT3-fs error (device ide0(3,9)) in ext3_reserve_inode_write: Journal has aborted kernel: EXT3-fs error (device ide0(3,9)) in ext3_dirty_inode: Journal has aborted kernel: ext3_abort called. kernel: EXT3-fs abort (device ide0(3,9)): ext3_journal_start: Detected aborted journal kernel: Remounting filesystem read-only kernel: EXT3-fs error (device ide0(3,9)) in start_transaction: Journal has aborted kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } kernel: hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=35484063, high=2, low=1929631, sector=1843880 kernel: end_request: I/O error, dev 03:06 (hda), sector 1843880 And later, similar errors on different partitions: kernel: EXT3-fs error (device ide0(3,6)): ext3_readdir: directory #444380 contains a hole at offset 0 kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } kernel: hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=40778463, high=2, low=7224031, sector=7138288 kernel: end_request: I/O error, dev 03:06 (hda), sector 7138288 kernel: EXT3-fs error (device ide0(3,6)): ext3_readdir: directory #444380 contains a hole at offset 0 kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } kernel: hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=126701370, high=7, low=9260858, sector=72096368 kernel: end_request: I/O error, dev 03:09 (hda), sector 72096368 kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } kernel: hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=126701366, high=7, low=9260854, sector=72096368 kernel: end_request: I/O error, dev 03:09 (hda), sector 72096368 kernel: EXT3-fs error (device ide0(3,9)): ext3_readdir: directory #1280449 contains a hole at offset 0 kernel: EXT3-fs error (device ide0(3,7)): ext3_readdir: directory #32771 contains a hole at offset 0 kernel: EXT3-fs error (device ide0(3,6)): ext3_readdir: directory #81961 contains a hole at offset 4096 kernel: EXT3-fs error (device ide0(3,3)) in start_transaction: Journal has aborted last message repeated 1535 times last message repeated 1134 times [etc] The sole drive in both of these machines is a rather run-of-the-mill model: # grep hda: dmesg hda: WDC WD1200JB-00EVA0, ATA DISK drive hda: 234441648 sectors (120034 MB) w/8192KiB Cache, CHS=232581/255/63 hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 > However, I notice some peculiarities with the on-board IDE interface: [from dmesg] Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PCI_IDE: unknown IDE controller on PCI bus 00 device f9, VID=8086, DID=24db PCI: Device 00:1f.1 not available because of resource collisions PCI_IDE: (ide_setup_pci_device:) Could not enable device. [from /proc/pci] Bus 0, device 31, function 1: IDE interface: PCI device 8086:24db (Intel Corp.) (rev 2). IRQ 18. I/O at 0x0 [0x7]. I/O at 0x0 [0x3]. I/O at 0x0 [0x7]. I/O at 0x0 [0x3]. I/O at 0xffa0 [0xffaf]. Non-prefetchable 32 bit memory at 0x3f000000 [0x3f0003ff]. Unfortunately I haven't had the ability myself to actually work with either of these machines yet, mainly due to 2000 miles of reality in between us. But I'm writing here as a favor to it's local admin. Does all of this ring any bells amongst the storage hackers here, maybe a well-known bug that was fixed long ago? Is there any reasonably up-to-date documentation out there on a standard diagnosis procedure for this sort of thing? Thanks, Jeremy From pegasus at nerv.eu.org Wed Jun 23 17:05:52 2004 From: pegasus at nerv.eu.org (Jure =?UTF-8?Q?Pe=C3=A8ar?=) Date: Wed, 23 Jun 2004 19:05:52 +0200 Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <871xkfroph.fsf@enki.rimspace.net> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <40D06C0B.7020005@techsource.com> <871xkfroph.fsf@enki.rimspace.net> Message-ID: <20040623190552.0241cddc.pegasus@nerv.eu.org> On Thu, 17 Jun 2004 10:51:54 +1000 Daniel Pittman wrote: > ext3 remains the only journaling filesystem that I would, personally, > put any great degree of faith in, since it is still developed in a > cautious and safe fashion, and has a focus on getting the tools to > verify correctness in place before enabling kernel-side features. I had more catastrophic losses of data on ext3 than on reiserfs. It turned out to be a power supply problem, but still ... reiserfs on the same disk survived just fine while ext3 was toasted beyond repair. YMMV. -- Jure Pe?ar From Ralf.Hildebrandt at charite.de Wed Jun 23 19:30:14 2004 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Wed, 23 Jun 2004 21:30:14 +0200 Subject: Which disk is it? Message-ID: <20040623193014.GA22269@charite.de> Which disk is it? /dev/sda6 or /dev/sdb8 or /dev/sdc6? >From my log: Jun 10 21:25:39 postamt1 kernel: attempt to access beyond end of device Jun 10 21:25:39 postamt1 kernel: 08:06: rw=0, want=1680353324, limit=59954548 Jun 10 21:25:39 postamt1 kernel: EXT3-fs error (device sd(8,6)): ext3_readdir: directory #3473659 contains a hole at offset 1852399616 $ mount /dev/sdb6 on / type auto (rw) none on /proc type proc (rw) /dev/sdb5 on /boot type ext3 (rw) /dev/sda6 on /home type ext3 (rw,nosuid,noatime) /dev/sdb8 on /tmp type ext3 (rw,nosuid,nocheck) /dev/sdb7 on /var type ext3 (rw,nosuid,noatime) /dev/sdb9 on /extra type ext3 (rw,noatime,data=journal,nocheck) /dev/hda6 on /mnt/hda type ext3 (rw,nosuid,noatime,nocheck) none on /dev/pts type devpts (rw,gid=5,mode=620) /dev/sdc6 on /copymail type ext3 (rw,nosuid,noatime,data=writeback,nocheck) -- Ralf Hildebrandt (Im Auftrag des Referat V a) Ralf.Hildebrandt at charite.de Charite - Universit?tsmedizin Berlin Tel. +49 (0)30-450 570-155 Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-916 IT-Zentrum Standort Campus Mitte AIM. ralfpostfix From evilninja at gmx.net Wed Jun 23 19:36:29 2004 From: evilninja at gmx.net (evilninja) Date: Wed, 23 Jun 2004 21:36:29 +0200 Subject: ide/ext3 errors on two identical machines In-Reply-To: <20040622155314.GA5970@foozle> References: <20040622155314.GA5970@foozle> Message-ID: <40D9DBBD.80502@gmx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeremy Dolan schrieb: > kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } > kernel: hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=54666719, high=3, low=4335071, sector=61720 [...] > [from dmesg] > Uniform Multi-Platform E-IDE driver Revision: 6.31 > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > PCI_IDE: unknown IDE controller on PCI bus 00 device f9, VID=8086, DID=24db > PCI: Device 00:1f.1 not available because of resource collisions > PCI_IDE: (ide_setup_pci_device:) Could not enable device. most likely hardware problems. were the 2 machines on the same power-line? maybe lightening caused a voltage peak on the machines? > up-to-date documentation out there on a standard diagnosis procedure for > this sort of thing? as usual: try to get contents to a new disk (oh, maybe it's the controllers fault, so change the controller then), try to fsck/mount the image, use your backups :-) Christian. - -- BOFH excuse #157: Incorrect time synchronization -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA2du9C/PVm5+NVoYRAl4QAKCyz9qWCtct/eBUq4FIxKyoSh9ppgCfTnvC x269dAWkbXGgNnjiJMD6ou4= =R+9V -----END PGP SIGNATURE----- From jrumpf at heavyload.net Wed Jun 23 19:38:57 2004 From: jrumpf at heavyload.net (Jeremy Rumpf) Date: Wed, 23 Jun 2004 15:38:57 -0400 Subject: Which disk is it? In-Reply-To: <20040623193014.GA22269@charite.de> References: <20040623193014.GA22269@charite.de> Message-ID: <200406231538.57331.jrumpf@heavyload.net> On Wednesday 23 June 2004 15:30 pm, Ralf Hildebrandt wrote: > Which disk is it? > /dev/sda6 or /dev/sdb8 or /dev/sdc6? > > From my log: > > Jun 10 21:25:39 postamt1 kernel: attempt to access beyond end of device > Jun 10 21:25:39 postamt1 kernel: 08:06: rw=0, want=1680353324, > limit=59954548 Jun 10 21:25:39 postamt1 kernel: EXT3-fs error (device > sd(8,6)): ext3_readdir: directory #3473659 contains a hole at offset > 1852399616 > > $ mount > /dev/sdb6 on / type auto (rw) > none on /proc type proc (rw) > /dev/sdb5 on /boot type ext3 (rw) > /dev/sda6 on /home type ext3 (rw,nosuid,noatime) > /dev/sdb8 on /tmp type ext3 (rw,nosuid,nocheck) > /dev/sdb7 on /var type ext3 (rw,nosuid,noatime) > /dev/sdb9 on /extra type ext3 (rw,noatime,data=journal,nocheck) > /dev/hda6 on /mnt/hda type ext3 (rw,nosuid,noatime,nocheck) > none on /dev/pts type devpts (rw,gid=5,mode=620) > /dev/sdc6 on /copymail type ext3 (rw,nosuid,noatime,data=writeback,nocheck) ls -l /dev | grep ' 8, *6 ' Should be sda6... HTH, Jeremy From manuaroste at yahoo.es Wed Jun 23 19:53:53 2004 From: manuaroste at yahoo.es (=?iso-8859-1?q?Manuel=20Arostegui=20Ramirez?=) Date: Wed, 23 Jun 2004 21:53:53 +0200 (CEST) Subject: Which disk is it? In-Reply-To: <20040623193014.GA22269@charite.de> Message-ID: <20040623195353.86344.qmail@web52404.mail.yahoo.com> --- Ralf Hildebrandt escribi?: > Which disk is it? > /dev/sda6 or /dev/sdb8 or /dev/sdc6? > > >From my log: > > Jun 10 21:25:39 postamt1 kernel: attempt to access > beyond end of device > Jun 10 21:25:39 postamt1 kernel: 08:06: rw=0, > want=1680353324, limit=59954548 > Jun 10 21:25:39 postamt1 kernel: EXT3-fs error > (device sd(8,6)): ext3_readdir: directory #3473659 > contains a hole at offset 1852399616 > > $ mount > /dev/sdb6 on / type auto (rw) > none on /proc type proc (rw) > /dev/sdb5 on /boot type ext3 (rw) > /dev/sda6 on /home type ext3 (rw,nosuid,noatime) > /dev/sdb8 on /tmp type ext3 (rw,nosuid,nocheck) > /dev/sdb7 on /var type ext3 (rw,nosuid,noatime) > /dev/sdb9 on /extra type ext3 > (rw,noatime,data=journal,nocheck) > /dev/hda6 on /mnt/hda type ext3 > (rw,nosuid,noatime,nocheck) > none on /dev/pts type devpts (rw,gid=5,mode=620) > /dev/sdc6 on /copymail type ext3 > (rw,nosuid,noatime,data=writeback,nocheck) A quickly explanation of SCSI Device Designation could be like that: sd(X,Y,Z) where: X=SCSI host interface, resident on the system bus. Y= Target ID number (of controller) multiplied by 8 possible SCSI devices for each target, plus the logical unit number of the device, it must be done in hex. Z= Partition number (or file number) After that you should know waht disk is sd(8,6)), don't you? Cheers ===== -- Manuel Ar?stegui Linux user 200896 http://manuel.todo-linux.com ______________________________________________ Renovamos el Correo Yahoo!: ?100 MB GRATIS! Nuevos servicios, m?s seguridad http://correo.yahoo.es From Ralf.Hildebrandt at charite.de Wed Jun 23 20:11:59 2004 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Wed, 23 Jun 2004 22:11:59 +0200 Subject: Which disk is it? In-Reply-To: <20040623195353.86344.qmail@web52404.mail.yahoo.com> References: <20040623193014.GA22269@charite.de> <20040623195353.86344.qmail@web52404.mail.yahoo.com> Message-ID: <20040623201159.GA24314@charite.de> * Manuel Arostegui Ramirez : > A quickly explanation of SCSI Device Designation could > be like that: > sd(X,Y,Z) > where: > X=SCSI host interface, resident on the system bus. > Y= Target ID number (of controller) multiplied by 8 > possible SCSI devices for each target, plus the > logical unit number of the device, it must be done in > hex. > Z= Partition number (or file number) > > After that you should know waht disk is sd(8,6)), > don't you? I ls -l'ed /dev/sd* and found out. fsck'ed it :) -- Ralf Hildebrandt (Im Auftrag des Referat V a) Ralf.Hildebrandt at charite.de Charite - Universit?tsmedizin Berlin Tel. +49 (0)30-450 570-155 Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-916 IT-Zentrum Standort Campus Mitte AIM. ralfpostfix From sam-williams at insightbb.com Thu Jun 24 05:23:23 2004 From: sam-williams at insightbb.com (Sam Williams) Date: Thu, 24 Jun 2004 00:23:23 -0500 Subject: Question Regarding e2fsck Message-ID: <1088054603.3763.59.camel@zurg> I've run ext3 filesystems for the last few years and I've never seen this question answered..... If a system shutsdown hard, even with journaling is it at all necessary to run e2fsck? Just curious.... Thanks -- Sam Williams samurai at acm.org +----------------------------------------------------------------------+ +"It is easy to be blinded to the essential uselessness of computers + + by the sense of accomplishment you get from getting them to work at + + all." + + - Douglas Adams + +----------------------------------------------------------------------+ From tytso at mit.edu Thu Jun 24 14:44:14 2004 From: tytso at mit.edu (Theodore Ts'o) Date: Thu, 24 Jun 2004 10:44:14 -0400 Subject: Question Regarding e2fsck In-Reply-To: <1088054603.3763.59.camel@zurg> References: <1088054603.3763.59.camel@zurg> Message-ID: <20040624144414.GA22249@thunk.org> On Thu, Jun 24, 2004 at 12:23:23AM -0500, Sam Williams wrote: > I've run ext3 filesystems for the last few years and I've never seen > this question answered..... If a system shutsdown hard, even with > journaling is it at all necessary to run e2fsck? It's best to just always run e2fsck. Yes, you can just simply mount an ext3 filesystem after a crash, since the kernel has code to run the journal; this is necessary if the root filesystem is a journalled ext3 filesystem. However, it's better to let userspace (i.e. fsck/e2fsck) take care of things from that point, for the following reasons: 1) E2fsck will run the journal automatically, and if the filesystem is otherwise clean, it skip doing a full filesystem check. 2) If the filesystem is not clean (because during the previous run the kernel noticed some filesystem inconsistencies), e2fsck will automatically do a full check if it is necessary. 3) If you have multiple disks, fsck will run multiple e2fsck processes in parallel, thus speeding up your boot sequence than if you let the kernel replay the journal for each filesystem when it tries to mount it, since then the journal replays will be done sequentially, instead of in parallel. The bottom line is that the all of the default major distributions are doing the right thing, and they are running e2fsck on ext3 filesystems for a good reason. So in answer to your question, no it is not ***necessary*** to run e2fsck, however, it is a good idea, and it will not slow down your boot time any to do so, and in fact if you have multiple hard drives, it will likely speed things up. - Ted From evilninja at gmx.net Thu Jun 24 22:57:14 2004 From: evilninja at gmx.net (evilninja) Date: Fri, 25 Jun 2004 00:57:14 +0200 Subject: filesystem screwed after aborted fsck.ext3 Message-ID: <40DB5C4A.70508@gmx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, a good friend of mine had some trouble with his fs yesterday. i have some details now and wonder if you have some thoughts on it, even it may turn out not to be an ext3 issue at all. sorry, the post is a bit too long: the ext3 fs was running for several months now on a RAID controller. due to a user error, the RAID controller decided to rebuild the (RAID-5) array, but only for one disk. iow: 6 disks were ok, 1 disk was to be rebuilt, 1 disk is hot-spare anyway. the rebuilt finished and indeed - the controller was visible again and my pal was able to mount the fs. although the mount seemed to be successful, there was a warning like "warning: mounting unlclean filesystem, need fs check" (no, i don't have the exact spelling at hand). hm, he somehow must have ignored this and continued to use the fs anyway. but it turned out, that several daemons would not start, and "some strange things" lead him to the assumption, that something must be wrong. so he fired up an fsck.ext3 on the (unmounted) fs. commiting several questions ("Fix? y|n") with "yes", my pal interrupted the check, and started again with "-y", so that fsck could run during the whole night and even still in the morning, so he interrupted it again. --> and now comes the worst part. after mounting the fs again, *all* files and directories were GONE! and lost+found is now filled up with 1.5e6 files and directories. the top-level dirs of lost+found are all named after (inode?)numbers, then we have directorynames/filenames too. but a lot of the files seem to be double and appear in several directories again. our task now would be to sorten out the "important" stuff, rename, find out what filename "0edakka.da" used to be and so on. as you can see, this is really a vague explanation of the issue here. i have no logfiles at hand, i can't send you the output of fsck/debugsfs runs a.t.m, but i'll be able to do all this later today, if it helps. all i can add is: this is a i386 SMP (amd 1900+), running debian/unstable (so we must have e2fsprogs 1.35 i think), kernel is vanilla 2.4.25 (or is it debian's version...?) i would be very happy, if someone has some hints on this. why moved e2fsck everything to lost+found, when the directory-structure was almost intact before? thanks in advance, Christian. - -- BOFH excuse #369: Virus transmitted from computer to sysadmins. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA21xKC/PVm5+NVoYRAsVZAJ99S7/QwZDOl6LOWYa7XQIJ6GNElwCeMHWJ 0qIKWsr1TfLH90BWDdW6bEE= =GMNg -----END PGP SIGNATURE----- From qfz at mail.ihep.ac.cn Thu Jun 24 06:01:11 2004 From: qfz at mail.ihep.ac.cn (Qi.fa.zhi) Date: Thu, 24 Jun 2004 14:01:11 +0800 (CST) Subject: help:about ext3 Message-ID: every one,I meet a problem: I used reahat9.0(kernel 2.4.20-8smp,I installed a SCSI RAID Card),and there are always some problems and them the system is dead. is anyone can help me about it? Thanks Crist Below is the error log: Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1382828372, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1481734211, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1364473155, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1631011121, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1667387002, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1450461527, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1464760387, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1333281386, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1483427379, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1515286576, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1366968918, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1430803027, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1262901843, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1366903384, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1497844272, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1362054507, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 175724083, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1350068835, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 2034911312, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 811877714, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1230647631, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1264220501, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1498573643, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1970292580, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 2001103951, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 863454543, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1917998409, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1262635096, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1718632778, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1900434263, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1194421580, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 2000185932, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1194678099, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1883592547, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 943221071, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1397633624, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1313297674, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 2000902721, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1684627760, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1178946125, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1681018710, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1164728148, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1517118251, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 2002084467, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 830100856, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1314280290, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1248481395, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1112952369, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 875648367, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1244810600, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1884379753, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1313099884, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1449940035, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1448627538, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 131408109e, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1834289765, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1464690807, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 811814449, count = 1 Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1801023343, count = 1 From pla at morecom.no Sun Jun 27 14:17:17 2004 From: pla at morecom.no (Petter Larsen) Date: Sun, 27 Jun 2004 16:17:17 +0200 Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <87wu26mto2.fsf@enki.rimspace.net> References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <40D06C0B.7020005@techsource.com> <1087460983.2765.34.camel@pla.lokal.lan> <87wu26mto2.fsf@enki.rimspace.net> Message-ID: <1088345837.5288.1.camel@pla.lokal.lan> > > We are using ext3 on a compact flash disk in an embedded device. So we > > are not using RAID systems. > > Watch out - even with the internal wear leveling the CF disk will do, > ext3 is still a pretty heavy filesystem to use there. > > Daniel Well, which filesystem would you then used for read-write on this CF? -- Petter Larsen cand. scient. moreCom as 913 17 222 From daniel at rimspace.net Mon Jun 28 00:22:17 2004 From: daniel at rimspace.net (Daniel Pittman) Date: Mon, 28 Jun 2004 10:22:17 +1000 Subject: mode data=journal in ext3. Is it safe to use? In-Reply-To: <1088345837.5288.1.camel@pla.lokal.lan> (Petter Larsen's message of "Sun, 27 Jun 2004 16:17:17 +0200") References: <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan> <1087322976.1874.36.camel@pla.lokal.lan> <40D06C0B.7020005@techsource.com> <1087460983.2765.34.camel@pla.lokal.lan> <87wu26mto2.fsf@enki.rimspace.net> <1088345837.5288.1.camel@pla.lokal.lan> Message-ID: <873c4g1qh2.fsf@enki.rimspace.net> On 28 Jun 2004, Petter Larsen wrote: >>> We are using ext3 on a compact flash disk in an embedded device. So we >>> are not using RAID systems. >> >> Watch out - even with the internal wear leveling the CF disk will do, >> ext3 is still a pretty heavy filesystem to use there. > > Well, which filesystem would you then used for read-write on this CF? My recommendation would be to look at running your system out of memory, and writing back to flash on a scheduled basis, and at shutdown. That way the write load is minimized, but you still have a persistent store. Daniel -- Anyone who goes to a psychiatrist ought to have his head examined. -- Samuel Goldwyn From petter.larsen at morecom.no Tue Jun 29 19:52:55 2004 From: petter.larsen at morecom.no (Petter Larsen) Date: Tue, 29 Jun 2004 21:52:55 +0200 Subject: SV: mode data=journal in ext3. Is it safe to use? Message-ID: <40FB8221D224C44393B0549DDB7A5CE80D45F3@tor.lokal.lan> >> >> Watch out - even with the internal wear leveling the CF disk will do, >> ext3 is still a pretty heavy filesystem to use there. > > Well, which filesystem would you then used for read-write on this CF? >My recommendation would be to look at running your system out of memory, >and writing back to flash on a scheduled basis, and at shutdown. >That way the write load is minimized, but you still have a persistent >store. > Daniel We will minimize disc access, but anyway we need a filesystem on the Compact Flash. Why do you not recomend ext3, and what would you use instead? Petter From venkatv at quinnfable.com Wed Jun 30 14:20:17 2004 From: venkatv at quinnfable.com (Venkat Reddy Valluri) Date: Wed, 30 Jun 2004 10:20:17 -0400 Subject: Mount 22 error mounting ext3 Message-ID: Hi, ON redhat 7.3, I moved some big directory form /usr to /home to adjust the space, We used more of hard disc using smart array controller, When I issued reboot on that server, I got hung giving the message given below Mount: 22 error mounting ext3 Can you please explain me why it happened Thks&Rgds --Venkat