On 2018/1/19 11:46, jiangyiwen wrote:
> mainline inclusion
> from v4.4-rc5
> commit 4ad78628445d26e5e9487b2e8f23274ad7b0f5d3
> category: bugfix
> bugzilla: 4404
> DTS: NA
> CVE: NA
> 补丁作用：对于块设备文件而言，->i_mapping与
> 普通文件不相同，如果文件中的数据来自于块设备
> 文件，则其->i_mapping将指向的是bd
mainline inclusion
from v4.4-rc5
commit 4ad78628445d26e5e9487b2e8f23274ad7b0f5d3
category: bugfix
bugzilla: 4404
DTS: NA
CVE: NA
补丁作用：对于块设备文件而言，->i_mapping与
普通文件不相同，如果文件中的数据来自于块设备
文件，则其->i_mapping将指向的是bdevfs inode
（master inode）的i_data，而->i_data实际是
empty的，因此在evict_inode的时候不应该释放
->i_mapping（bdevfs_i
Hi guys,
I'm sorry if someone else has already asked the same question before,
but here's what we are facing with scsi mid-level.
Variables of bit-field in struct scsi_device are not protected by
lock, such as no_report_opcodes, is_visible and so on. I guess
everyone think these variable can't be
On 2016/2/5 11:13, Martin K. Petersen wrote:
>>>>>> "Yiwen" == jiangyiwen writes:
>
> Yiwen,
>
> Yiwen> First, I don't understand why blk_peek_request() return
> Yiwen> EREMOTEIO, as I know, in this situation we only prepare scsi
&
commit 8af1954d172a("blkdev: Do not return -EOPNOTSUPP if discard
is supported") only solve the situation of discard, because When
applications issue a discard request to device, they can't expect
deterministic behaviour. However, WRITE SAME should not ignore error
with EOPNOTSUPP, because if appli
On 2016/2/5 11:13, Martin K. Petersen wrote:
>>>>>> "Yiwen" == jiangyiwen writes:
>
> Yiwen,
>
> Yiwen> First, I don't understand why blk_peek_request() return
> Yiwen> EREMOTEIO, as I know, in this situation we only prepare scsi
&
On 2016/2/4 14:48, Martin K. Petersen wrote:
> When a storage device rejects a WRITE SAME command we will disable write
> same functionality for the device and return -EREMOTEIO to the block
> layer. -EREMOTEIO will in turn prevent DM from retrying the I/O and/or
> failing the path.
>
> Yiwen Jian
On 2016/2/4 12:25, Mike Snitzer wrote:
> On Wed, Feb 03 2016 at 10:49pm -0500,
> jiangyiwen wrote:
>
>> On 2016/2/4 11:24, Mike Snitzer wrote:
>>> On Wed, Feb 03 2016 at 9:08pm -0500,
>>> jiangyiwen wrote:
>>>
>>>> When two processes
On 2016/2/4 11:24, Mike Snitzer wrote:
> On Wed, Feb 03 2016 at 9:08pm -0500,
> jiangyiwen wrote:
>
>> When two processes submit WRTIE SAME bio simultaneously and
>> first IO return failed because of INVALID FIELD IN CDB, and
>> then second IO can enter into an infini
When two processes submit WRTIE SAME bio simultaneously and
first IO return failed because of INVALID FIELD IN CDB, and
then second IO can enter into an infinite loop.
The problem can be described as follows:
process 1 process 2
submit_bio(REQ_WRITE_SAME) and
wait io c
10 matches
Mail list logo
