Ext3 is supported not well at 2.6.28 for external SD card removal

Ext3 is supported not well at 2.6.28 for external SD card removal

[Peter Chen]

Dear all,

I find the kernel 2.6.28 is supported ext3 for SD card not well.
The external SD card is formatted with ext3, and when removal from
sd slot, it prints below ext3_abort msg. Such message isn't occurred at
Linux 2.6.23 and 2.6.27.

mmc1: card d555 removed
mmcblk2: error -110 sending read/write command
mmcblk2: error -110 requesting status
end_request: I/O error, dev mmcblk2, sector 1576855
Buffer I/O error on device mmcblk2p1, logical block 197099
lost page write due to I/O error on mmcblk2p1
mmcblk2: error -110 sending read/write command
mmcblk2: error -110 requesting status
end_request: I/O error, dev mmcblk2, sector 1576863
Buffer I/O error on device mmcblk2p1, logical block 197100
lost page write due to I/O error on mmcblk2p1
Aborting journal on device mmcblk2p1.
------------[ cut here ]------------
WARNING: at 
/home/nchen/work/L28EVB/Dev/sirfa5cb_l28_alpha/kernel/fs/buffer.c:1195 
mark_buffer_dirty+0x9c/0xb8()
Modules linked in: sirfsoc_wdt sirfsoc_uspserial g_ether g_usbdrv 
ehci_hcd usbcore snd_soc_cb_modac_ts snd_soc_modac snd_soc_sirfsoc_i2s snd_s
oc_ts_stream_mode snd_soc_sirfsoc snd_soc_core snd_pcm snd_timer snd 
soundcore snd_page_alloc sirfsoc_bl sirfsoc_fb cfbcopyarea cfbimgblt cfbf
illrect
[<c008a8d8>] (dump_stack+0x0/0x14) from [<c009edfc>] 
(warn_on_slowpath+0x4c/0x68)
[<c009edb0>] (warn_on_slowpath+0x0/0x68) from [<c011c1b0>] 
(mark_buffer_dirty+0x9c/0xb8)
  r6:c0ad1000 r5:c0340970 r4:c349b7f0
[<c011c114>] (mark_buffer_dirty+0x0/0xb8) from [<c015b84c>] 
(journal_update_superblock+0xcc/0x14c)
  r5:c3a319c0 r4:c38da000
[<c015b780>] (journal_update_superblock+0x0/0x14c) from [<c015ba84>] 
(__journal_abort_soft+0xc8/0xd8)
  r7:c38da000 r6:fffffffb r5:c3a319c0 r4:c38da000
[<c015b9bc>] (__journal_abort_soft+0x0/0xd8) from [<c015baa4>] 
(journal_abort+0x10/0x14)
  r6:c3493860 r5:fffffffb r4:c349b748
[<c015ba94>] (journal_abort+0x0/0x14) from [<c0158324>] 
(journal_commit_transaction+0xa64/0x14a0)
[<c01578c0>] (journal_commit_transaction+0x0/0x14a0) from [<c015c6d8>] 
(kjournald+0xc4/0x29c)
[<c015c614>] (kjournald+0x0/0x29c) from [<c00b5818>] (kthread+0x54/0x80)
[<c00b57c4>] (kthread+0x0/0x80) from [<c00a1ec8>] (do_exit+0x0/0x818)
  r5:00000000 r4:00000000
---[ end trace 494b15a74f793f7d ]---
mmcblk2: error -110 sending read/write command
mmcblk2: error -110 requesting status
end_request: I/O error, dev mmcblk2, sector 1576855
Buffer I/O error on device mmcblk2p1, logical block 197099
lost page write due to I/O error on mmcblk2p1
journal commit I/O error
ext3_abort called.
EXT3-fs error (device mmcblk2p1): ext3_put_super: Couldn't clean up the 
journal
Remounting filesystem read-only

Besides, I find when system goes to suspend, when we remove sd card 
after the system has already suspended. Then, press wakeup button, the 
system can't wakeup. It sounds happens
deadlock at __fsync_super, which call stack likes below:
mmc_remove_card-->device_del-->mmc_blk_remove-->del_gendisk

Such action is ok at Linux 2.6.23 and 2.6.27. And sd card with vfat at 
2.6.28 is ok.

Does anyone know what happening for ext3 at 2.6.28 ( or from 2.6.28)?
Any solutions for such issue?

Thank you!

-- 
Best regards,
Peter Chen

Ext3 is supported not well at 2.6.28 for external SD card removal

[Marek Vasut]

Dne Po 19. ??jna 2009 07:38:35 Peter Chen napsal(a):
> Dear all,
> 
> I find the kernel 2.6.28 is supported ext3 for SD card not well.
> The external SD card is formatted with ext3, and when removal from
> sd slot, it prints below ext3_abort msg. Such message isn't occurred at
> Linux 2.6.23 and 2.6.27.
> 
> mmc1: card d555 removed
> mmcblk2: error -110 sending read/write command
> mmcblk2: error -110 requesting status
> end_request: I/O error, dev mmcblk2, sector 1576855
> Buffer I/O error on device mmcblk2p1, logical block 197099
> lost page write due to I/O error on mmcblk2p1
> mmcblk2: error -110 sending read/write command
> mmcblk2: error -110 requesting status
> end_request: I/O error, dev mmcblk2, sector 1576863
> Buffer I/O error on device mmcblk2p1, logical block 197100
> lost page write due to I/O error on mmcblk2p1
> Aborting journal on device mmcblk2p1.
> ------------[ cut here ]------------
> WARNING: at
> /home/nchen/work/L28EVB/Dev/sirfa5cb_l28_alpha/kernel/fs/buffer.c:1195
> mark_buffer_dirty+0x9c/0xb8()
> Modules linked in: sirfsoc_wdt sirfsoc_uspserial g_ether g_usbdrv
> ehci_hcd usbcore snd_soc_cb_modac_ts snd_soc_modac snd_soc_sirfsoc_i2s
>  snd_s oc_ts_stream_mode snd_soc_sirfsoc snd_soc_core snd_pcm snd_timer snd
>  soundcore snd_page_alloc sirfsoc_bl sirfsoc_fb cfbcopyarea cfbimgblt cfbf
>  illrect
> [<c008a8d8>] (dump_stack+0x0/0x14) from [<c009edfc>]
> (warn_on_slowpath+0x4c/0x68)
> [<c009edb0>] (warn_on_slowpath+0x0/0x68) from [<c011c1b0>]
> (mark_buffer_dirty+0x9c/0xb8)
>   r6:c0ad1000 r5:c0340970 r4:c349b7f0
> [<c011c114>] (mark_buffer_dirty+0x0/0xb8) from [<c015b84c>]
> (journal_update_superblock+0xcc/0x14c)
>   r5:c3a319c0 r4:c38da000
> [<c015b780>] (journal_update_superblock+0x0/0x14c) from [<c015ba84>]
> (__journal_abort_soft+0xc8/0xd8)
>   r7:c38da000 r6:fffffffb r5:c3a319c0 r4:c38da000
> [<c015b9bc>] (__journal_abort_soft+0x0/0xd8) from [<c015baa4>]
> (journal_abort+0x10/0x14)
>   r6:c3493860 r5:fffffffb r4:c349b748
> [<c015ba94>] (journal_abort+0x0/0x14) from [<c0158324>]
> (journal_commit_transaction+0xa64/0x14a0)
> [<c01578c0>] (journal_commit_transaction+0x0/0x14a0) from [<c015c6d8>]
> (kjournald+0xc4/0x29c)
> [<c015c614>] (kjournald+0x0/0x29c) from [<c00b5818>] (kthread+0x54/0x80)
> [<c00b57c4>] (kthread+0x0/0x80) from [<c00a1ec8>] (do_exit+0x0/0x818)
>   r5:00000000 r4:00000000
> ---[ end trace 494b15a74f793f7d ]---
> mmcblk2: error -110 sending read/write command
> mmcblk2: error -110 requesting status
> end_request: I/O error, dev mmcblk2, sector 1576855
> Buffer I/O error on device mmcblk2p1, logical block 197099
> lost page write due to I/O error on mmcblk2p1
> journal commit I/O error
> ext3_abort called.
> EXT3-fs error (device mmcblk2p1): ext3_put_super: Couldn't clean up the
> journal
> Remounting filesystem read-only
> 
> Besides, I find when system goes to suspend, when we remove sd card
> after the system has already suspended. Then, press wakeup button, the
> system can't wakeup. It sounds happens
> deadlock at __fsync_super, which call stack likes below:
> mmc_remove_card-->device_del-->mmc_blk_remove-->del_gendisk
> 
> Such action is ok at Linux 2.6.23 and 2.6.27. And sd card with vfat at
> 2.6.28 is ok.
> 
> Does anyone know what happening for ext3 at 2.6.28 ( or from 2.6.28)?
> Any solutions for such issue?

You popped the card out without unmounting the filesystem I guess ?
> 
> Thank you!
> 

Ext3 is supported not well at 2.6.28 for external SD card removal

[tommy.hong]

hi,you can try EXT4!ext3 is not stable in arm,one of my friends need some ext3 bug in 2.6.25,can cause system halt!



?2009-10-19?13:59:11?"Marek?Vasut"?<marek.vasut@gmail.com>????
>Dne?Po?19.???jna?2009?07:38:35?Peter?Chen?napsal(a):
>>?Dear?all,
>>?
>>?I?find?the?kernel?2.6.28?is?supported?ext3?for?SD?card?not?well.
>>?The?external?SD?card?is?formatted?with?ext3,?and?when?removal?from
>>?sd?slot,?it?prints?below?ext3_abort?msg.?Such?message?isn't?occurred?at
>>?Linux?2.6.23?and?2.6.27.
>>?
>>?mmc1:?card?d555?removed
>>?mmcblk2:?error?-110?sending?read/write?command
>>?mmcblk2:?error?-110?requesting?status
>>?end_request:?I/O?error,?dev?mmcblk2,?sector?1576855
>>?Buffer?I/O?error?on?device?mmcblk2p1,?logical?block?197099
>>?lost?page?write?due?to?I/O?error?on?mmcblk2p1
>>?mmcblk2:?error?-110?sending?read/write?command
>>?mmcblk2:?error?-110?requesting?status
>>?end_request:?I/O?error,?dev?mmcblk2,?sector?1576863
>>?Buffer?I/O?error?on?device?mmcblk2p1,?logical?block?197100
>>?lost?page?write?due?to?I/O?error?on?mmcblk2p1
>>?Aborting?journal?on?device?mmcblk2p1.
>>?------------[?cut?here?]------------
>>?WARNING:?at
>>?/home/nchen/work/L28EVB/Dev/sirfa5cb_l28_alpha/kernel/fs/buffer.c:1195
>>?mark_buffer_dirty+0x9c/0xb8()
>>?Modules?linked?in:?sirfsoc_wdt?sirfsoc_uspserial?g_ether?g_usbdrv
>>?ehci_hcd?usbcore?snd_soc_cb_modac_ts?snd_soc_modac?snd_soc_sirfsoc_i2s
>>??snd_s?oc_ts_stream_mode?snd_soc_sirfsoc?snd_soc_core?snd_pcm?snd_timer?snd
>>??soundcore?snd_page_alloc?sirfsoc_bl?sirfsoc_fb?cfbcopyarea?cfbimgblt?cfbf
>>??illrect
>>?[<c008a8d8>]?(dump_stack+0x0/0x14)?from?[<c009edfc>]
>>?(warn_on_slowpath+0x4c/0x68)
>>?[<c009edb0>]?(warn_on_slowpath+0x0/0x68)?from?[<c011c1b0>]
>>?(mark_buffer_dirty+0x9c/0xb8)
>>???r6:c0ad1000?r5:c0340970?r4:c349b7f0
>>?[<c011c114>]?(mark_buffer_dirty+0x0/0xb8)?from?[<c015b84c>]
>>?(journal_update_superblock+0xcc/0x14c)
>>???r5:c3a319c0?r4:c38da000
>>?[<c015b780>]?(journal_update_superblock+0x0/0x14c)?from?[<c015ba84>]
>>?(__journal_abort_soft+0xc8/0xd8)
>>???r7:c38da000?r6:fffffffb?r5:c3a319c0?r4:c38da000
>>?[<c015b9bc>]?(__journal_abort_soft+0x0/0xd8)?from?[<c015baa4>]
>>?(journal_abort+0x10/0x14)
>>???r6:c3493860?r5:fffffffb?r4:c349b748
>>?[<c015ba94>]?(journal_abort+0x0/0x14)?from?[<c0158324>]
>>?(journal_commit_transaction+0xa64/0x14a0)
>>?[<c01578c0>]?(journal_commit_transaction+0x0/0x14a0)?from?[<c015c6d8>]
>>?(kjournald+0xc4/0x29c)
>>?[<c015c614>]?(kjournald+0x0/0x29c)?from?[<c00b5818>]?(kthread+0x54/0x80)
>>?[<c00b57c4>]?(kthread+0x0/0x80)?from?[<c00a1ec8>]?(do_exit+0x0/0x818)
>>???r5:00000000?r4:00000000
>>?---[?end?trace?494b15a74f793f7d?]---
>>?mmcblk2:?error?-110?sending?read/write?command
>>?mmcblk2:?error?-110?requesting?status
>>?end_request:?I/O?error,?dev?mmcblk2,?sector?1576855
>>?Buffer?I/O?error?on?device?mmcblk2p1,?logical?block?197099
>>?lost?page?write?due?to?I/O?error?on?mmcblk2p1
>>?journal?commit?I/O?error
>>?ext3_abort?called.
>>?EXT3-fs?error?(device?mmcblk2p1):?ext3_put_super:?Couldn't?clean?up?the
>>?journal
>>?Remounting?filesystem?read-only
>>?
>>?Besides,?I?find?when?system?goes?to?suspend,?when?we?remove?sd?card
>>?after?the?system?has?already?suspended.?Then,?press?wakeup?button,?the
>>?system?can't?wakeup.?It?sounds?happens
>>?deadlock?at?__fsync_super,?which?call?stack?likes?below:
>>?mmc_remove_card-->device_del-->mmc_blk_remove-->del_gendisk
>>?
>>?Such?action?is?ok?at?Linux?2.6.23?and?2.6.27.?And?sd?card?with?vfat?at
>>?2.6.28?is?ok.
>>?
>>?Does?anyone?know?what?happening?for?ext3?at?2.6.28?(?or?from?2.6.28)?
>>?Any?solutions?for?such?issue?
>
>You?popped?the?card?out?without?unmounting?the?filesystem?I?guess??
>>?
>>?Thank?you!
>>?
>
>_______________________________________________
>linux-arm-kernel?mailing?list
>linux-arm-kernel at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20091019/f6321cae/attachment.htm>

Ext3 is supported not well at 2.6.28 for external SD card removal

[Peter Chen]

Marek Vasut wrote:
> Dne Po 19. ??jna 2009 07:38:35 Peter Chen napsal(a):
>> Dear all,
>>
>> I find the kernel 2.6.28 is supported ext3 for SD card not well.
>> The external SD card is formatted with ext3, and when removal from
>> sd slot, it prints below ext3_abort msg. Such message isn't occurred at
>> Linux 2.6.23 and 2.6.27.
>>
>> mmc1: card d555 removed
>> mmcblk2: error -110 sending read/write command
>> mmcblk2: error -110 requesting status
>> end_request: I/O error, dev mmcblk2, sector 1576855
>> Buffer I/O error on device mmcblk2p1, logical block 197099
>> lost page write due to I/O error on mmcblk2p1
>> mmcblk2: error -110 sending read/write command
>> mmcblk2: error -110 requesting status
>> end_request: I/O error, dev mmcblk2, sector 1576863
>> Buffer I/O error on device mmcblk2p1, logical block 197100
>> lost page write due to I/O error on mmcblk2p1
>> Aborting journal on device mmcblk2p1.
>> ------------[ cut here ]------------
>> WARNING: at
>> /home/nchen/work/L28EVB/Dev/sirfa5cb_l28_alpha/kernel/fs/buffer.c:1195
>> mark_buffer_dirty+0x9c/0xb8()
>> Modules linked in: sirfsoc_wdt sirfsoc_uspserial g_ether g_usbdrv
>> ehci_hcd usbcore snd_soc_cb_modac_ts snd_soc_modac snd_soc_sirfsoc_i2s
>>  snd_s oc_ts_stream_mode snd_soc_sirfsoc snd_soc_core snd_pcm snd_timer snd
>>  soundcore snd_page_alloc sirfsoc_bl sirfsoc_fb cfbcopyarea cfbimgblt cfbf
>>  illrect
>> [<c008a8d8>] (dump_stack+0x0/0x14) from [<c009edfc>]
>> (warn_on_slowpath+0x4c/0x68)
>> [<c009edb0>] (warn_on_slowpath+0x0/0x68) from [<c011c1b0>]
>> (mark_buffer_dirty+0x9c/0xb8)
>>   r6:c0ad1000 r5:c0340970 r4:c349b7f0
>> [<c011c114>] (mark_buffer_dirty+0x0/0xb8) from [<c015b84c>]
>> (journal_update_superblock+0xcc/0x14c)
>>   r5:c3a319c0 r4:c38da000
>> [<c015b780>] (journal_update_superblock+0x0/0x14c) from [<c015ba84>]
>> (__journal_abort_soft+0xc8/0xd8)
>>   r7:c38da000 r6:fffffffb r5:c3a319c0 r4:c38da000
>> [<c015b9bc>] (__journal_abort_soft+0x0/0xd8) from [<c015baa4>]
>> (journal_abort+0x10/0x14)
>>   r6:c3493860 r5:fffffffb r4:c349b748
>> [<c015ba94>] (journal_abort+0x0/0x14) from [<c0158324>]
>> (journal_commit_transaction+0xa64/0x14a0)
>> [<c01578c0>] (journal_commit_transaction+0x0/0x14a0) from [<c015c6d8>]
>> (kjournald+0xc4/0x29c)
>> [<c015c614>] (kjournald+0x0/0x29c) from [<c00b5818>] (kthread+0x54/0x80)
>> [<c00b57c4>] (kthread+0x0/0x80) from [<c00a1ec8>] (do_exit+0x0/0x818)
>>   r5:00000000 r4:00000000
>> ---[ end trace 494b15a74f793f7d ]---
>> mmcblk2: error -110 sending read/write command
>> mmcblk2: error -110 requesting status
>> end_request: I/O error, dev mmcblk2, sector 1576855
>> Buffer I/O error on device mmcblk2p1, logical block 197099
>> lost page write due to I/O error on mmcblk2p1
>> journal commit I/O error
>> ext3_abort called.
>> EXT3-fs error (device mmcblk2p1): ext3_put_super: Couldn't clean up the
>> journal
>> Remounting filesystem read-only
>>
>> Besides, I find when system goes to suspend, when we remove sd card
>> after the system has already suspended. Then, press wakeup button, the
>> system can't wakeup. It sounds happens
>> deadlock at __fsync_super, which call stack likes below:
>> mmc_remove_card-->device_del-->mmc_blk_remove-->del_gendisk
>>
>> Such action is ok at Linux 2.6.23 and 2.6.27. And sd card with vfat at
>> 2.6.28 is ok.
>>
>> Does anyone know what happening for ext3 at 2.6.28 ( or from 2.6.28)?
>> Any solutions for such issue?
> 
> You popped the card out without unmounting the filesystem I guess ?
We don't execute umount at 2.6.27/23 either, and it has little error:
[   32.541208] Buffer I/O error on device mmcblk1p1, logical block 0
[   32.544784] lost page write due to I/O error on mmcblk1p1

Besides, the remove card is ok after suspend at 2.6.27 and 2.6.23.

Usually, the remove card(ext3) without umount is forbiddon or not?
I know the ext3 default is journal filesystem, and the write-back
execution is delayed 5 seconds.

>> Thank you!
>>
> 

-- 
Best regards,
Peter Chen

Ext3 is supported not well at 2.6.28 for external SD card removal

[Uwe Kleine-König]

Hello,

On Mon, Oct 19, 2009 at 03:46:11PM +0800, Peter Chen wrote:
> Marek Vasut wrote:
>> Dne Po 19. ??jna 2009 07:38:35 Peter Chen napsal(a):
>> You popped the card out without unmounting the filesystem I guess ?
> We don't execute umount at 2.6.27/23 either, and it has little error:
> [   32.541208] Buffer I/O error on device mmcblk1p1, logical block 0
> [   32.544784] lost page write due to I/O error on mmcblk1p1
>
> Besides, the remove card is ok after suspend at 2.6.27 and 2.6.23.
>
> Usually, the remove card(ext3) without umount is forbiddon or not?
You shouldn't remove the card without unmounting first.  And you should
unmount with .23 and .27, too.  Just because these kernels don't wail it
doesn't mean you cannot loose data.

Best regards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-K?nig            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

Ext3 is supported not well at 2.6.28 for external SD card removal

[Peter Chen]

Uwe Kleine-K?nig wrote:
> Hello,
> 
> On Mon, Oct 19, 2009 at 03:46:11PM +0800, Peter Chen wrote:
>> Marek Vasut wrote:
>>> Dne Po 19. ??jna 2009 07:38:35 Peter Chen napsal(a):
>>> You popped the card out without unmounting the filesystem I guess ?
>> We don't execute umount at 2.6.27/23 either, and it has little error:
>> [   32.541208] Buffer I/O error on device mmcblk1p1, logical block 0
>> [   32.544784] lost page write due to I/O error on mmcblk1p1
>>
>> Besides, the remove card is ok after suspend at 2.6.27 and 2.6.23.
>>
>> Usually, the remove card(ext3) without umount is forbiddon or not?
> You shouldn't remove the card without unmounting first.  And you should
> unmount with .23 and .27, too.  Just because these kernels don't wail it
> doesn't mean you cannot loose data.
> 
> Best regards
> Uwe
> 
I find the system still will be deadlock if i use sync before go to suspend.
I wonder why system will go to deadlock even there is not card at slot.

-- 
Best regards,
Peter Chen

Ext3 is supported not well at 2.6.28 for external SD card removal

[Steve Chen]

On Mon, 2009-10-19 at 16:29 +0800, Peter Chen wrote:
> Uwe Kleine-K?nig wrote:
> > Hello,
> > 
> > On Mon, Oct 19, 2009 at 03:46:11PM +0800, Peter Chen wrote:
> >> Marek Vasut wrote:
> >>> Dne Po 19. ??jna 2009 07:38:35 Peter Chen napsal(a):
> >>> You popped the card out without unmounting the filesystem I guess ?
> >> We don't execute umount at 2.6.27/23 either, and it has little error:
> >> [   32.541208] Buffer I/O error on device mmcblk1p1, logical block 0
> >> [   32.544784] lost page write due to I/O error on mmcblk1p1
> >>
> >> Besides, the remove card is ok after suspend at 2.6.27 and 2.6.23.
> >>
> >> Usually, the remove card(ext3) without umount is forbiddon or not?
> > You shouldn't remove the card without unmounting first.  And you should
> > unmount with .23 and .27, too.  Just because these kernels don't wail it
> > doesn't mean you cannot loose data.
> > 
> > Best regards
> > Uwe
> > 
> I find the system still will be deadlock if i use sync before go to suspend.
> I wonder why system will go to deadlock even there is not card at slot.
> 

Is this specific to ext3?  Does it happen to other file systems such as
xfs?

Regards,

Steve

Ext3 is supported not well at 2.6.28 for external SD card removal

[Daniel Mack]

On Mon, Oct 19, 2009 at 02:12:36PM +0800, tommy.hong wrote:
> hi,you can try EXT4!ext3 is not stable in arm,one of my friends need some ext3 bug in 2.6.25,can cause system halt!

What kind of bug are you referring to? Did you speak to the vfs/ext3
people about that?

We've been using ext3 on ARM on mass storage media for quite some time,
without facing any serious issues.

Daniel

Ext3 is supported not well at 2.6.28 for external SD card removal

[Russell King - ARM Linux]

On Mon, Oct 19, 2009 at 02:12:36PM +0800, tommy.hong wrote:
> hi,you can try EXT4!ext3 is not stable in arm,one of my friends need
> some ext3 bug in 2.6.25,can cause system halt!

ext3 works fine - it's been used on the old mailing list server for its
filesystems for hundreds of days (on that exact kernel version) without
issue.

It's also being used on the web server and older web server both without
any incident.

All aforementioned machines are ARM based.  I can only assume that you
have local (unreported) issues with ext3 on ARM.

Ext3 is supported not well at 2.6.28 for external SD card removal

[Peter Chen]

Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2009 at 02:12:36PM +0800, tommy.hong wrote:
>> hi,you can try EXT4!ext3 is not stable in arm,one of my friends need
>> some ext3 bug in 2.6.25,can cause system halt!
> 
> ext3 works fine - it's been used on the old mailing list server for its
> filesystems for hundreds of days (on that exact kernel version) without
> issue.
> 
> It's also being used on the web server and older web server both without
> any incident.
> 
> All aforementioned machines are ARM based.  I can only assume that you
> have local (unreported) issues with ext3 on ARM.
> 
The problem I found was removing SD card with ext3 without unmount, It 
is ok at 2.6.27 and 2.6.23, but bad at 2.6.28 ( or later, I am not sure).

The problems with ext3 partitioned are:
1. We remove the SD card after the system go to suspend, then, after the 
system resume. The system is go to deadlock at __fsync_super: the call
stack like below:
mmc_remove_card-->device_del-->mmc_blk_remove-->del_gendisk

2. When removing SD card without unmount during the system is running, 
there are below errors:
mmc1: card d555 removed
mmcblk2: error -110 sending read/write command
mmcblk2: error -110 requesting status
end_request: I/O error, dev mmcblk2, sector 1576855
Buffer I/O error on device mmcblk2p1, logical block 197099
lost page write due to I/O error on mmcblk2p1
mmcblk2: error -110 sending read/write command
mmcblk2: error -110 requesting status
end_request: I/O error, dev mmcblk2, sector 1576863
Buffer I/O error on device mmcblk2p1, logical block 197100
lost page write due to I/O error on mmcblk2p1
Aborting journal on device mmcblk2p1.
------------[ cut here ]------------
WARNING: at 
/home/nchen/work/L28EVB/Dev/sirfa5cb_l28_alpha/kernel/fs/buffer.c:1195 
mark_buffer_dirty+0x9c/0xb8()
Modules linked in: sirfsoc_wdt sirfsoc_uspserial g_ether g_usbdrv 
ehci_hcd usbcore snd_soc_cb_modac_ts snd_soc_modac snd_soc_sirfsoc_i2s snd_s
oc_ts_stream_mode snd_soc_sirfsoc snd_soc_core snd_pcm snd_timer snd 
soundcore snd_page_alloc sirfsoc_bl sirfsoc_fb cfbcopyarea cfbimgblt cfbf
illrect
[<c008a8d8>] (dump_stack+0x0/0x14) from [<c009edfc>] 
(warn_on_slowpath+0x4c/0x68)
[<c009edb0>] (warn_on_slowpath+0x0/0x68) from [<c011c1b0>] 
(mark_buffer_dirty+0x9c/0xb8)
  r6:c0ad1000 r5:c0340970 r4:c349b7f0
[<c011c114>] (mark_buffer_dirty+0x0/0xb8) from [<c015b84c>] 
(journal_update_superblock+0xcc/0x14c)
  r5:c3a319c0 r4:c38da000
[<c015b780>] (journal_update_superblock+0x0/0x14c) from [<c015ba84>] 
(__journal_abort_soft+0xc8/0xd8)
  r7:c38da000 r6:fffffffb r5:c3a319c0 r4:c38da000
[<c015b9bc>] (__journal_abort_soft+0x0/0xd8) from [<c015baa4>] 
(journal_abort+0x10/0x14)
  r6:c3493860 r5:fffffffb r4:c349b748
[<c015ba94>] (journal_abort+0x0/0x14) from [<c0158324>] 
(journal_commit_transaction+0xa64/0x14a0)
[<c01578c0>] (journal_commit_transaction+0x0/0x14a0) from [<c015c6d8>] 
(kjournald+0xc4/0x29c)
[<c015c614>] (kjournald+0x0/0x29c) from [<c00b5818>] (kthread+0x54/0x80)
[<c00b57c4>] (kthread+0x0/0x80) from [<c00a1ec8>] (do_exit+0x0/0x818)
  r5:00000000 r4:00000000
---[ end trace 494b15a74f793f7d ]---
mmcblk2: error -110 sending read/write command
mmcblk2: error -110 requesting status
end_request: I/O error, dev mmcblk2, sector 1576855
Buffer I/O error on device mmcblk2p1, logical block 197099
lost page write due to I/O error on mmcblk2p1
journal commit I/O error
ext3_abort called.
EXT3-fs error (device mmcblk2p1): ext3_put_super: Couldn't clean up the 
journal
Remounting filesystem read-only

The above two problems weren't happened at 2.6.27/23 kernel, and with 
vfat partition.

I wonder such two operations are forbidden for ext3 , especially after 
2.6.27 or there is something wrong with our code?

Thank you!

_______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

-- 
Best regards,
Peter Chen

Ext3 is supported not well at 2.6.28 for external SD card removal

[Russell King - ARM Linux]

On Tue, Oct 20, 2009 at 01:34:24PM +0800, Peter Chen wrote:
> The problem I found was removing SD card with ext3 without unmount, It  
> is ok at 2.6.27 and 2.6.23, but bad at 2.6.28 ( or later, I am not sure).

As has already been pointed out, removing media without unmounting it
first is highly risky - you're risking data loss in spite of ext3
being a journalling filesystem.

The other thing to think about is that with a block based journalling
filesystem, a flash-based device is going to get a higher number of
writes, and therefore will wear out (and therefore fail) quicker.  You
might be better off with some other filesystem (eg, vfat) on the SD
card.

Lastly, try reporting the problem somewhere more appropriate, such as
the ext2 maintainers/mailing list and the SD mailing list.