> -----Original Message-----
> From: Bart Van Assche [mailto:bart.vanass...@wdc.com]
> Sent: Friday, August 18, 2017 4:06 PM
> To: h...@infradead.org; Viswas G <viswa...@microsemi.com>; Gerry
> Morong <gerry.mor...@microsemi.com>; Mahesh Rajashekhara
> <mahesh.rajashekh...@microsemi.com>; posw...@suse.com; Scott
> Benesh <scott.ben...@microsemi.com>; Don Brace
> <don.br...@microsemi.com>; Bader Ali - Saleh
> <bader.alisa...@microsemi.com>; Kevin Barnett
> <kevin.barn...@microsemi.com>; joseph.szczy...@hpe.com; Scott Teel
> <scott.t...@microsemi.com>; j...@linux.vnet.ibm.com; Justin Lindley
> <justin.lind...@microsemi.com>; John Hall <john.h...@microsemi.com>
> Cc: linux-scsi@vger.kernel.org
> Subject: Re: [PATCH] sd: preserve sysfs updates to max_sectors_kb
> 
> EXTERNAL EMAIL
> 
> 
> On Fri, 2017-08-18 at 16:00 -0500, Don Brace wrote:
> > prevent systemd-udevd from changing a device's sysfs entry
> > max_sectors_kb back to the default value.
> >  - max_sectors_kb can be tweaked for better performance.
> >  - udev can be triggered by sg_logs -t or scsi_temperature, ...
> >  - sd_revalidate_disk is called from udev by ioctl BLKRRPART
> 
> Hello Don,
> 
> Which udev rule changes max_sectors_kb back to the default? Why do you
> want
> to change the kernel code instead of modifying that udev rule? What
> software
> changes max_sectors_kb to a smaller value? Is it a udev rule or perhaps
> something else?
> 
> Thanks,
> 
> Bart.

As far as I can see, udev looks for file access in sysfs. 
I am not exactly sure which rule changes this. It was added in more recent
distros. Can someone help me out?

I wanted to change the kernel code because it looks to me like anytime
sd_revalidate_disk is called max_sectors is reset to its maximum value. Anyone
tweaking max_sectors_kb for performance reasons will find that it is not
persistent.

If this distills down to a simpler rule change, then all the better.

From my testing:

I set /sys/block/sdd/queue/max_sectors_kb to some value.
    echo 64 > /sys/block/sdd/queue/max_sectors_kb
I run sg_logs -t /dev/sdd and the value is reset back to its original value.
Other utilities can also trigger udev to run. 

udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[8537223.347520] change   
/devices/pci0000:00/0000:00:03.0/0000:08:00.0/host4/port-4:4/end_device-4:4/target4:0:3/4:0:3:0/block/sdd
 (block)
UDEV  [8537223.399243] change   
/devices/pci0000:00/0000:00:03.0/0000:08:00.0/host4/port-4:4/end_device-4:4/target4:0:3/4:0:3:0/block/sdd
 (block)
...
manager->fd_inotify = udev_watch_init(manager->udev);
       sd_event_add_io(manager->event, &manager->inotify_event, 
manager->fd_inotify, EPOLLIN, on_inotify, manager);
           on_inotify (systemd source code: src/udev/udevd.c)
              synthesize_change
                    ioctl --> BLKRRPART
                              ----------------------
                              Start of kernel code.
                              ----------------------
                              blkdev_ioctl (block/ioctl.c)
                                   CASE:BLKRRPART: blkdev_reread_part 
(block/ioctl.c)
                                         _blkdev_reread_part (block/ioctl.c)
                                                rescan_partitions 
(block/partition-generic.c)
                                                     if 
(disk->fops->revalidate_disk)
                                                         
disk->fops->revalidate_disk(disk);
                                                           
----------------------------------
                                                           sd driver 
(drivers/scsi/sd.c
                                                           sd_revalidate_disk


Thanks for your input,
Don Brace
ESC - Smart Storage
Microsemi Corporation


Reply via email to