回复：块层介绍第一部分 - 块 I/O 层
内核
回复：amarao 在[块层介绍第一部分：块 I/O 层](https://lwn.net/Articles/737588/) 中提的问题


先前的文章：[块层介绍第一部分：块 I/O 层](https://lwn.net/Articles/736534/)


![](/data/attachment/album/201712/03/111453ac1rfngngbnb2fct.png)


嗨，


你在这里描述的问题与块层不直接相关。这可能是一个驱动错误、可能是一个 SCSI 层错误，但绝对不是一个块层的问题。


不幸的是，报告针对 Linux 的错误是一件难事。有些开发者拒绝去看 bugzilla，有些开发者喜欢它，有些（像我这样）只能勉强地使用它。


另一种方法是发送电子邮件。为此，你需要选择正确的邮件列表，还有也许是正确的开发人员，当他们心情愉快，或者不是太忙或者不是假期时找到它们。有些人会努力回复所有，有些是完全不可预知的 - 这对我来说通常会发送一个补丁，包含一些错误报告。如果你只是有一个你自己几乎都不了解的 bug，那么你的预期响应率可能会更低。很遗憾，但这是是真的。


许多 bug 都会得到回应和处理，但很多 bug 都没有。


我不认为说没有人关心是公平的，但是没有人认为它如你想的那样重要是有可能的。如果你想要一个解决方案，那么你需要驱动它。一个驱动它的方法是花钱请顾问或者与经销商签订支持合同。我怀疑你的情况没有上面的可能。另一种方法是了解代码如何工作，并自己找到解决方案。很多人都这么做，但是这对你来说可能不是一种选择。另一种方法是在不同的相关论坛上不断提出问题，直到得到回复。坚持可以见效。你需要做好准备去执行任何你所要求的测试，可能包括建立一个新的内核来测试。


如果你能在最近的内核(4.12 或者更新)上复现这个 bug，我建议你邮件报告给 [linux-kernel@vger.kernel.org](mailto:linux-kernel@vger.kernel.org)、[linux-scsi@vger.kernel.org](mailto:linux-scsi@vger.kernel.org) 和我（[neilb@suse.com](mailto:neilb@suse.com)）（注意你不必订阅这些列表来发送邮件，只需要发送就行）。描述你的硬件以及如何触发问题的。


包含所有进程状态是 “D” 的栈追踪。你可以用 “cat /proc/$PID/stack” 来得到它，这里的 “$PID” 是进程的 pid。


确保避免抱怨或者说这个已经坏了好几年了以及这是多么严重不足。没有人关心这个。我们关心的是 bug 以及如何修复它。因此只要报告相关的事实就行。


尝试在邮件中而不是链接到其他地方的链接中包含所有事实。有时链接是需要的，但是对于你的脚本，它只有 8 行，所以把它包含在邮件中就行（并避免像 “fuckup” 之类的描述。只需称它为<ruby> “坏的” <rp>  （ </rp> <rt>  broken </rt> <rp>  ） </rp></ruby>或者类似的）。同样确保你的邮件发送的不是 HTML 格式。我们喜欢纯文本。HTML 被所有的 @vger.kernel.org 邮件列表拒绝。你或许需要配置你的邮箱程序不发送 HTML。




---


via: <https://lwn.net/Articles/737655/>


作者：[neilbrown](https://lwn.net/Articles/737655/) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
# A block layer introduction part 1: the bio layer

## A block layer introduction part 1: the bio layer

Posted Oct 29, 2017 4:56 UTC (Sun) by**neilbrown**(subscriber, #359)

In reply to:

[A block layer introduction part 1: the bio layer](/Articles/737588/)by amarao

Parent article:

[A block layer introduction part 1: the bio layer](/Articles/736534/)


the problem you describe here is not directly related to the block layer. It is probably a driver bug, possible a SCSI-layer bug, but definitely not a block-layer problem.

Reporting bugs against Linux is, unfortunately, a bit of a hit-and-miss affair. Some developers refused to touch bugzilla, some love it, and some (like me) only use it begrudgingly.

The alternative is to send email. For that you need to choose the right list and maybe the right developer, and you need to catch them when they are in a good mood or aren't too busy or not on holidays. Some people will make an effort to respond to everything, others are completely unpredictable - and that is for me who usually sends a patch with any bug report. If you just have a bug that you barely understand yourself, your expected response rate is probably lower. Sad, but true.

Lots of bugs do get responded to and dealt with, but lots do not.


I don't think it is fair to say that nobody cares, but it probably is true that nobody sees it as being as important as you do. If you want a solution, then you need to drive it. One way to drive it is to spend money on a consultant or with a support contract from a distributor. I suspect that isn't possible in your situation. Another way is to learn how the code works and find a solution yourself. Lots of people do that, but again it might not be an option for you. Another way is to keep raising the issue on different relevant forums until you get a response. Persistence can bear fruit. You would need to be prepared to perform whatever testing is asked of you, possibly including building a new kernel to test.


If you are able to reproduce this problem on a recent kernel (4.12 or later) I suggest that you email a report to

linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, and me (neilb@suse.com) (note that you do not need to subscribe to these lists to send mail, just send it). Describe the hardware and how to trigger the problem.

Include the stack trace of any process in "D" state. You can get this with

cat /proc/$PID/stack

where "$PID" is the pid of the process.


Be sure to avoid complaining or saying how this has been broken for years and how it is grossly inadequate. Nobody cares about that. We do care about bugs and generally want to fix them. So just report the relevant facts.

Try to include all facts in the mail rather than via links to somewhere else. Sometimes links are necessary, but in the case of your script, it is 8 lines long so just include it in the email (and avoid descriptions like "fuckup"; just call it "broken" or similar). Also make sure your email isn't sent as HTML. We like just plain text. HTML is rejected by all @vger.kernel.org mailing lists. You might need to configure your email program to not send HTML.