[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] [RFC] New interface for dm-io to handle timed requests

Stefan Bader wrote:
dm-devel-bounces redhat com wrote on 14.03.2006 21:15:10:

Stefan Bader wrote:

The ideal solution would be to have an interface in the block layer

allows us to cancel any submitted requests. But since such a change

take quite a lot discussions and work, we want to emulate such a behavior in the dm core for now.

The scsi people and some block people have been talking about moving more error handling functionality into the block layer for a while and it is slowing moving that way. It could probably be done faster if people did not concentrate on one subsystem :)

It is not that much about error handling. More about policy. If the
subsystem decides that io took enough time or maybe it just doesn't
want to go on (could be a force umount...) it would be nice to be
able to stop lower level drivers from doing error recovery. Thus
the idea of stopping a submitted request.

Ah ok sorry, I think I call it error handling becuase if a command is running on the disk or on the transport then for LLDs like scsi canceling the command is part of our error handling code. Sorry for the confusion.

But setting the limit for the command's running time can be moved to the block layer away from the llds and higher levels so we can all coordinate this. If the command times out the block layer can begin to cancel the command and call into the LLD (we would actually have to stack the cancel command callout like the request_fns or do the block request queue as message queue junk) to handle the lower level details of how to cancel it.

The changes to the core now shall fake this as long as there isn't
such a functionality in the kernel with an interface that can handle

Maybe you should post to lkml and linux-scsi and get some responses from

them before adding it to dm core. If a post already went out to those list my fault for missing it.

No it didn't. I guess lkml is a good point. I am not sure about linux-scsi.
As it is not related specifically to scsi...

Well, you need to convert linux-scsi and many people on the list have been thinking about how to do it so that is why I suggested it.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]