> -----Original Message----- > From: Bart Van Assche [mailto:Bart.VanAssche@xxxxxxx] > Sent: Friday, August 18, 2017 4:06 PM > To: hch@xxxxxxxxxxxxx; Viswas G <viswas.g@xxxxxxxxxxxxx>; Gerry > Morong <gerry.morong@xxxxxxxxxxxxx>; Mahesh Rajashekhara > <mahesh.rajashekhara@xxxxxxxxxxxxx>; POSWALD@xxxxxxxx; Scott > Benesh <scott.benesh@xxxxxxxxxxxxx>; Don Brace > <don.brace@xxxxxxxxxxxxx>; Bader Ali - Saleh > <bader.alisaleh@xxxxxxxxxxxxx>; Kevin Barnett > <kevin.barnett@xxxxxxxxxxxxx>; joseph.szczypek@xxxxxxx; Scott Teel > <scott.teel@xxxxxxxxxxxxx>; jejb@xxxxxxxxxxxxxxxxxx; Justin Lindley > <justin.lindley@xxxxxxxxxxxxx>; John Hall <John.Hall@xxxxxxxxxxxxx> > Cc: linux-scsi@xxxxxxxxxxxxxxx > 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
