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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This would be a cosmetic fix.
The problem is that there is no good logic so the attached device use
the optimal read_capacity based on storage size.
I mean, I can understand that it is safer to go for read_capacity10
first because of the jungle of the USB attached storages, but when you
realize that read_capacity16 works and because of the storage size you
must use it, then I think the scsi layer shall go for it

2018-03-10 11:29 GMT+01:00 Christoph Hellwig <hch@xxxxxxxxxxxxx>:
> On Tue, Mar 06, 2018 at 09:40:56AM +0100, Menion wrote:
>> Hi all
>> Operating big capacity HDD such 8TB with complex filesystems like
>> BTRFS in RAID mode endup in dmesg get flooded by this log, due too
>> many capacity checks (opaque to the filesystem itself)
>> The logs come from here:
>>
>> https://elixir.bootlin.com/linux/latest/source/drivers/scsi/sd.c#L2508
>>
>> The general guideline tells that KERN_NOTICE (which is the default log
>> level for dmesg in most distribution) should report information for
>> any user interest
>> I think that this information is not really of user interest, rather
>> more of DEBUG interest
>> So my suggestion is to lower this log to KERN_DEBUG
>> Do you agree?
>
> That warning and log level is correct, but maybe we can add a flag
> so that we only print the warning once per device?




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux