Jens Axboe writes:
> On 10/30/2015 09:34 AM, Jeff Moyer wrote:
>> From: Vivek Goyal
>>
>> If a block device is hot removed and later last reference to device
>> is put, we try to writeback the dirty inode. But device is gone and
>> that writeback fails.
>>
>> Currently we do a WARN_ON() which
Jens Axboe writes:
> On 10/30/2015 09:34 AM, Jeff Moyer wrote:
>> From: Vivek Goyal
>>
>> If a block device is hot removed and later last reference to device
>> is put, we try to writeback the dirty inode. But device is gone and
>> that writeback fails.
>>
>>
On 10/30/2015 09:34 AM, Jeff Moyer wrote:
From: Vivek Goyal
If a block device is hot removed and later last reference to device
is put, we try to writeback the dirty inode. But device is gone and
that writeback fails.
Currently we do a WARN_ON() which does not seem to be the right thing.
From: Vivek Goyal
If a block device is hot removed and later last reference to device
is put, we try to writeback the dirty inode. But device is gone and
that writeback fails.
Currently we do a WARN_ON() which does not seem to be the right thing.
Convert it to a ratelimited kernel warning.
On 10/30/2015 09:34 AM, Jeff Moyer wrote:
From: Vivek Goyal
If a block device is hot removed and later last reference to device
is put, we try to writeback the dirty inode. But device is gone and
that writeback fails.
Currently we do a WARN_ON() which does not seem to be
From: Vivek Goyal
If a block device is hot removed and later last reference to device
is put, we try to writeback the dirty inode. But device is gone and
that writeback fails.
Currently we do a WARN_ON() which does not seem to be the right thing.
Convert it to a ratelimited
6 matches
Mail list logo