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 tha
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://
>> static int sd_try_rc16_first(struct scsi_device *sdp)
>> {
>> if (sdp->host->max_cmd_len < 16)
>> return 0;
>
>
> option
>
>> if (sdp->try_rc_10_first)
>> return 0;
>
>
> option
>
>> if (sdp->scsi_level > SCSI_SPC_2)
>> retu
Menion,
> I means, the last_lba is read from the responde of read_capacity_10 in
> scsiReadCapacity10 via this conversion:
>
> if (last_lbap)
> *last_lbap = get_unaligned_be32(resp + 0);
>
> so are you sure that if the device return more than about 4TB the
> value of this variable wil
Menion,
> So, assuming that there is no disconnection ad USB level (and it is
> not since I don't get any log of it), the question is: how can trigger
> a probe or call the sd_revalidate_disk? Can it be the filesystem?
revalidate is either a function of either device discovery following a
contr
neither, there are no dbg for kernel ppa in ubuntu :(
2018-03-08 12:10 GMT+01:00 Steffen Maier :
>
> On 03/08/2018 12:07 PM, Menion wrote:
>>
>> Unfortunately the Ubuntu kernel is not configured for ftrace or
>> kprobe, and I am operating this server so I am not sure if I will
>> eventually find t
On 03/08/2018 12:07 PM, Menion wrote:
Unfortunately the Ubuntu kernel is not configured for ftrace or
kprobe, and I am operating this server so I am not sure if I will
eventually find the time and the risk to install a self-compiled
kernel
systemtap?
Unfortunately the Ubuntu kernel is not configured for ftrace or
kprobe, and I am operating this server so I am not sure if I will
eventually find the time and the risk to install a self-compiled
kernel
2018-03-08 11:53 GMT+01:00 Steffen Maier :
>
> On 03/08/2018 11:34 AM, Menion wrote:
>>
>> I did
On 03/08/2018 11:34 AM, Menion wrote:
I did some more test
This log is specific from the function sd_read_capacitysd_revalidate_disk
From what I can see, it seems that it is called only when probing
newly attached devices
A quick look in the code I see that it is called by sd_revalidate_disk
T
I did some more test
This log is specific from the function sd_read_capacitysd_revalidate_disk
>From what I can see, it seems that it is called only when probing
newly attached devices
A quick look in the code I see that it is called by sd_revalidate_disk
This function is registered by fops for th
Anyhow, I checked something that I should have checked since the beginning.
I have stopped smartd and I still get this log, so it is something
else doing it, but does anyone have an idea how understand what
subsystem is calling again and again the read_capacity_10?
2018-03-08 10:16 GMT+01:00 Menio
Hi
I have tried it, but it does not work:
[ 39.230095] sd 0:0:0:0: [sda] Very big device. Trying to use READ
CAPACITY(16).
[ 39.338032] sd 0:0:0:1: [sdb] Very big device. Trying to use READ
CAPACITY(16).
[ 39.618268] sd 0:0:0:2: [sdc] Very big device. Trying to use READ
CAPACITY(16).
[ 39.
On 2018-03-07 09:02 AM, Menion wrote:
2018-03-07 14:51 GMT+01:00 Steffen Maier :
On 03/07/2018 09:24 AM, Menion wrote:
...
but from then on, you only get it roughly once every 300 seconds, i.e. 5
minutes
that's where I suspect user space as trigger, unless there is a kernel
feature I'm not
2018-03-07 14:51 GMT+01:00 Steffen Maier :
>
> On 03/07/2018 09:24 AM, Menion wrote:
>>
> ...
>
> but from then on, you only get it roughly once every 300 seconds, i.e. 5
> minutes
>
> that's where I suspect user space as trigger, unless there is a kernel
> feature I'm not aware of doing such sdev
On 03/07/2018 09:24 AM, Menion wrote:
By flooded I mean that it continously fill the dmesg log with no
interruption, check attached a log that I have just taken from my
server
Some more details on my setup. I have these 5 HDD, WD RED 8TB in an
Orico 5 bay enclosure, running JMS567 USBtoSATA brid
Hello Martin
Thanks for your answer.
By flooded I mean that it continously fill the dmesg log with no
interruption, check attached a log that I have just taken from my
server
Some more details on my setup. I have these 5 HDD, WD RED 8TB in an
Orico 5 bay enclosure, running JMS567 USBtoSATA bridge a
Menion,
> 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)
What's your definition of flooded? How many do you see?
Also, what kind of controller are the
17 matches
Mail list logo
