Re: WARNING: at fs/buffer.c:1186 mark_buffer_dirty+0x51/0x66() - Kernel

This is a discussion on Re: WARNING: at fs/buffer.c:1186 mark_buffer_dirty+0x51/0x66() - Kernel ; On Saturday 25 October 2008 03:10, Vladislav Bolkhovitin wrote: > Hi, > > During recent debugging session of my SCSI target SCST > ( http://scst.sf.net ) I noticed many > > WARNING: at fs/buffer.c:1186 mark_buffer_dirty+0x51/0x66() > > messages in kernel ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Re: WARNING: at fs/buffer.c:1186 mark_buffer_dirty+0x51/0x66()

  1. Re: WARNING: at fs/buffer.c:1186 mark_buffer_dirty+0x51/0x66()

    On Saturday 25 October 2008 03:10, Vladislav Bolkhovitin wrote:
    > Hi,
    >
    > During recent debugging session of my SCSI target SCST
    > (http://scst.sf.net) I noticed many
    >
    > WARNING: at fs/buffer.c:1186 mark_buffer_dirty+0x51/0x66()
    >
    > messages in kernel log on the initiator. I attached the full log of
    > several of them.
    >
    > My target was buggy and I was working on fixing it, but I suppose Linux
    > should handle such failures more gracefully. In all the cases the target
    > had one type of failure: it "ate" a SCSI command and never returned
    > result of it.


    Right. This is one of the warnings I see in my fault-injection testing.
    It is fixed by my patch to clean up and improve the page and buffer
    error handling in the vm/fs.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: WARNING: at fs/buffer.c:1186 mark_buffer_dirty+0x51/0x66()

    Nick Piggin wrote:
    > On Saturday 25 October 2008 03:10, Vladislav Bolkhovitin wrote:
    >> Hi,
    >>
    >> During recent debugging session of my SCSI target SCST
    >> (http://scst.sf.net) I noticed many
    >>
    >> WARNING: at fs/buffer.c:1186 mark_buffer_dirty+0x51/0x66()
    >>
    >> messages in kernel log on the initiator. I attached the full log of
    >> several of them.
    >>
    >> My target was buggy and I was working on fixing it, but I suppose Linux
    >> should handle such failures more gracefully. In all the cases the target
    >> had one type of failure: it "ate" a SCSI command and never returned
    >> result of it.

    >
    > Right. This is one of the warnings I see in my fault-injection testing.
    > It is fixed by my patch to clean up and improve the page and buffer
    > error handling in the vm/fs.


    Can you specify which patch you referring? Is it in 2.6.27?
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: WARNING: at fs/buffer.c:1186 mark_buffer_dirty+0x51/0x66()

    On Wednesday 29 October 2008 06:38, Vladislav Bolkhovitin wrote:
    > Nick Piggin wrote:
    > > On Saturday 25 October 2008 03:10, Vladislav Bolkhovitin wrote:
    > >> Hi,
    > >>
    > >> During recent debugging session of my SCSI target SCST
    > >> (http://scst.sf.net) I noticed many
    > >>
    > >> WARNING: at fs/buffer.c:1186 mark_buffer_dirty+0x51/0x66()
    > >>
    > >> messages in kernel log on the initiator. I attached the full log of
    > >> several of them.
    > >>
    > >> My target was buggy and I was working on fixing it, but I suppose Linux
    > >> should handle such failures more gracefully. In all the cases the target
    > >> had one type of failure: it "ate" a SCSI command and never returned
    > >> result of it.

    > >
    > > Right. This is one of the warnings I see in my fault-injection testing.
    > > It is fixed by my patch to clean up and improve the page and buffer
    > > error handling in the vm/fs.

    >
    > Can you specify which patch you referring? Is it in 2.6.27?


    It's just an RFC at the moment which I posted to fsdevel. Not in 2.6.27.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: WARNING: at fs/buffer.c:1186 mark_buffer_dirty+0x51/0x66()

    Nick Piggin wrote:
    > On Wednesday 29 October 2008 06:38, Vladislav Bolkhovitin wrote:
    >> Nick Piggin wrote:
    >>> On Saturday 25 October 2008 03:10, Vladislav Bolkhovitin wrote:
    >>>> Hi,
    >>>>
    >>>> During recent debugging session of my SCSI target SCST
    >>>> (http://scst.sf.net) I noticed many
    >>>>
    >>>> WARNING: at fs/buffer.c:1186 mark_buffer_dirty+0x51/0x66()
    >>>>
    >>>> messages in kernel log on the initiator. I attached the full log of
    >>>> several of them.
    >>>>
    >>>> My target was buggy and I was working on fixing it, but I suppose Linux
    >>>> should handle such failures more gracefully. In all the cases the target
    >>>> had one type of failure: it "ate" a SCSI command and never returned
    >>>> result of it.
    >>> Right. This is one of the warnings I see in my fault-injection testing.
    >>> It is fixed by my patch to clean up and improve the page and buffer
    >>> error handling in the vm/fs.

    >> Can you specify which patch you referring? Is it in 2.6.27?

    >
    > It's just an RFC at the moment which I posted to fsdevel. Not in 2.6.27.


    I see. I'm looking forward to see it in 2.6.28 or .29. This is really a
    needed work.

    BTW, have you even seen in your fault-injection testing that after
    receiving a failure from a SCSI device during heavy load ext3 file
    system mounted on it gets corrupted and journal replay on remount
    doesn't repair it, only manual e2fsck helps? I've many times seen that,
    including cases when the target was remaining up and fully functional.
    See, e.g., "MOANING MODE ON" part in
    http://marc.info/?l=linux-scsi&m=121932252324432&w=2. I haven't checked
    that case since then, although I see such corruptions quite often. But
    in all them I can't so clearly say that it isn't a target's failure.

    Vlad

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: WARNING: at fs/buffer.c:1186 mark_buffer_dirty+0x51/0x66()

    On Saturday 01 November 2008 05:11, Vladislav Bolkhovitin wrote:
    > Nick Piggin wrote:
    > > On Wednesday 29 October 2008 06:38, Vladislav Bolkhovitin wrote:
    > >> Nick Piggin wrote:
    > >>> On Saturday 25 October 2008 03:10, Vladislav Bolkhovitin wrote:
    > >>>> Hi,
    > >>>>
    > >>>> During recent debugging session of my SCSI target SCST
    > >>>> (http://scst.sf.net) I noticed many
    > >>>>
    > >>>> WARNING: at fs/buffer.c:1186 mark_buffer_dirty+0x51/0x66()
    > >>>>
    > >>>> messages in kernel log on the initiator. I attached the full log of
    > >>>> several of them.
    > >>>>
    > >>>> My target was buggy and I was working on fixing it, but I suppose
    > >>>> Linux should handle such failures more gracefully. In all the cases
    > >>>> the target had one type of failure: it "ate" a SCSI command and never
    > >>>> returned result of it.
    > >>>
    > >>> Right. This is one of the warnings I see in my fault-injection testing.
    > >>> It is fixed by my patch to clean up and improve the page and buffer
    > >>> error handling in the vm/fs.
    > >>
    > >> Can you specify which patch you referring? Is it in 2.6.27?

    > >
    > > It's just an RFC at the moment which I posted to fsdevel. Not in 2.6.27.

    >
    > I see. I'm looking forward to see it in 2.6.28 or .29. This is really a
    > needed work.


    Hopefully. Unfortunately it doesn't exactly make the filesystems
    themselves more robust against failure. That needs to be done on
    a case by case basis.


    > BTW, have you even seen in your fault-injection testing that after
    > receiving a failure from a SCSI device during heavy load ext3 file
    > system mounted on it gets corrupted and journal replay on remount
    > doesn't repair it, only manual e2fsck helps? I've many times seen that,
    > including cases when the target was remaining up and fully functional.
    > See, e.g., "MOANING MODE ON" part in
    > http://marc.info/?l=linux-scsi&m=121932252324432&w=2. I haven't checked
    > that case since then, although I see such corruptions quite often. But
    > in all them I can't so clearly say that it isn't a target's failure.


    I haven't seen that, but I'm not exactly testing for filesystem
    robustness to errors, but more of core vm/fs layer robustness, so
    I'm mainly trying to inject errors into data portion of inodes.

    I think the ext3 development list should be interested in your
    report.

    Thanks,
    Nick
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread