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 <men...@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 <men...@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 <dste...@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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
