Re: Failing a bio right

[Tomer Margalit]

Hi Jan,

I had a bug and that's what probably caused the problems (still need to verify).

However, I still get the I/O error on device warning.
Is that warning expected? And is this the right way of interrupting a
disk write?

Thanks,
  Tomer

On Mon, Jan 23, 2012 at 10:14 PM, Jan Kara <jack@xxxxxxx> wrote:
>
> On Sun 22-01-12 11:29:44, Tomer Margalit wrote:
> > Hi Jav,
> >
> > Thanks for the reply.
> >
> > On Fri, Jan 20, 2012 at 4:01 PM, Jan Kara <jack@xxxxxxx> wrote:
> > >  Hello,
> > >
> > > On Thu 19-01-12 18:04:19, Tomer Margalit wrote:
> > >> I have a make_request function that blocks writes (by using
> > >> wait_event_interruptible on some event).
> > >> I want the user to be able to stop the function if it takes too long
> > >> (that's the reason for the interruptible version).
> > >> So when the call is interrupted I call bio_endio with the EINTR error
> > >> to signal the interruption.
> > >> Usually this works fine, but after a lot of writes, the system says
> > >> "lost page write due to I/O error on device".
> > >  This is because end_buffer_write_sync() doesn't really distinguish
> > > errors.  So when some error happens it complains about I/O error.
> > >
> > >> At this point the process hangs.
> > >  That is strange - you should probably collect stack trace of the failing
> > > process (e.g. via 'echo w >/proc/sysrq-trigger'). That should tell us more.
> > >
> >
> > I cannot get a stack trace of the process since it hangs (probably in
> > the write) - for instance doing 'gdb -p PID` or `strace -p PID` causes
> > those to hang as well. The process doesn't segfault either.
>  That's why I told you to use 'echo w >/proc/sysrq-trigger' and looking
> at dmesg.
>
> > >> Is this the right way to do what I'm trying to do?
> > >  I'm not sure how is it supposed to work. Writes happen usually in an
> >
> > The bdev I am creating is a virtual disk that replicates writes to a
> > remote location. My intention is that it will behave like a socket -
> > i.e. block until writes can be done. Actually the bdev is additionally
> > meant to be semi-synchronous, so that after a buffer is filled, all
> > writes are blocked until some buffers are sent to the remote end.
> >
> > This works in principle, but when I try to cancel a write which is
> > taking too long (for instance 100MB), it doesn't do anything (since
> > it's stuck in the kernel).
> >
> > > async manner (through page cache and flusher thread) or are you using
> > > direct IO? Also if a write is interrupted at this point, you just lost the
> >
> > All of this behavior happens when I do the final fsync(2) after all
> > the data has been written.
> >
> > > content of the buffer (as it is marked clean and !uptodate). Users usually
> > > don't like that.
> > >
> >
> > I don't mind about contents lost since the user doesn't want to wait
> > until the end of the write (if done without flush it may take as long
> > as it requires, but flushing means wait until writes are done).
> >
> > As a side note, I use the fsync since I have also implemented a
> > marking mechanism for the bdev - and before creating a mark I need to
> > make sure all previous writes have been flushed.
>  OK, I see. Let's see what the stack traces of the hung process are.
>
>                                                                Honza
> --
> Jan Kara <jack@xxxxxxx>
> SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/