Re: dmesg flooded with "Very big device. Trying to use READ CAPACITY(16)" with 8TB HDDs

[Menion <menion@gmail.com>]

Actually this path can be taken in few occurrency

1) device probe, only when the device is plugged or detected the first time
2) revalidate_disk fops of block device

Is it possible that BTRFS every 5 minutes call the revalidate_disk?

2018-03-08 11:16 GMT+01:00 Menion <menion@gmail.com>:
> Hi again
> I had a discussion in linux-scsi about this topic
> My understanding is that it is true that the read_capacity is opaque
> to the filesystem but it is also true that the scsi layer export two
> specific read_capacity ops, the read10 and read16 and the upper layers
> shall select the proper one, based on the response of the other.
> In the log, I see that this read_capacity_10 is called every 5
> minutes, and it fallback to read_capacity_16, since who is doing it
> endup in calling sd_read_capacity in scsi layer, rather then pickup
> read10 or read16 directly
> I am not telling that BTRFS is doing it for sure, but I have ruled out
> smartd, so based on the periodicity of 5 minutes, can you think about
> anything in the BTRFS internals that can be responsible of this?
>
> 2018-03-02 17:19 GMT+01:00 Menion <menion@gmail.com>:
>> Thanks
>> My point was to understand if this action was taken by BTRFS or
>> automously by scsi.
>> From your word it seems clear to me that this should go in
>> KERNEL_DEBUG level, instead of KERNEL_NOTICE
>> Bye
>>
>> 2018-03-02 16:18 GMT+01:00 David Sterba <dsterba@suse.cz>:
>>> On Fri, Mar 02, 2018 at 12:37:49PM +0100, Menion wrote:
>>>> Is it really a no problem? I mean, for some reason BTRFS is
>>>> continuously read the HDD capacity in an array, that does not seem to
>>>> be really correct
>>>
>>> The message comes from SCSI:
>>> https://elixir.bootlin.com/linux/latest/source/drivers/scsi/sd.c#L2508
>>>
>>> Reading drive capacity could be totally opaque for the filesystem, eg.
>>> when the scsi layer compares the requested block address with the device
>>> size.
>>>
>>> The sizes of blockdevices is obtained from the i_size member of the
>>> inode representing the block device, so there's no direct read by btrfs.
>>> You'd have better luck reporting that to scsi or block layer
>>> mailinglists.