RE: [PATCH] sd: preserve sysfs updates to max_sectors_kb

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

 



________________________________________
From: Don Brace
Sent: Monday, August 21, 2017 1:14 PM
To: Bart Van Assche; hch@xxxxxxxxxxxxx; Viswas G; Gerry Morong; Mahesh Rajashekhara; POSWALD@xxxxxxxx; Scott Benesh; Bader Ali - Saleh; Kevin Barnett; joseph.szczypek@xxxxxxx; Scott Teel; jejb@xxxxxxxxxxxxxxxxxx; Justin Lindley; John Hall
Cc: linux-scsi@xxxxxxxxxxxxxxx
Subject: RE: [PATCH] sd: preserve sysfs updates to max_sectors_kb

> -----Original Message-----
> From: Bart Van Assche [mailto:Bart.VanAssche@xxxxxxx]
> Sent: Monday, August 21, 2017 2:53 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 Mon, 2017-08-21 at 19:12 +0000, Don Brace wrote:
> > On Friday Bart Van Assche wrote:
> > > Can you check on your test system which udev rule changes
> > > max_sectors_kb? I
> > > have checked two recent Linux distro's but haven't been able to find
> > > such a udev rule:
> > > $ grep -rw max_sectors_kb /usr/lib/udev/rules.d /etc/udev/rules.d | wc
> > > -l
> > > 0
> > >
> > > Thanks,
> > >
> > > Bart.
> >
> > On my system it is 60-block.rules, and it is the last rule in that rule
> > file.
> > --
> > # do not edit this file, it will be overwritten on update
> >
> > # enable in-kernel media-presence polling
> > ACTION=="add", SUBSYSTEM=="module", KERNEL=="block",
> > ATTR{parameters/events_dfl_poll_msecs}=="0", \
> >   ATTR{parameters/events_dfl_poll_msecs}="2000"
> >
> > # forward scsi device event to corresponding block device
> > ACTION=="change", SUBSYSTEM=="scsi", ENV{DEVTYPE}=="scsi_device",
> > TEST=="block", ATTR{block/*/uevent}="change"
> >
> > # watch metadata changes, caused by tools closing the device node which
> > was opened for writing
> > ACTION!="remove", SUBSYSTEM=="block",
> > KERNEL=="loop*|nvme*|sd*|vd*|xvd*|pmem*", OPTIONS+="watch"
>
> Hello Don,
>
> Can you have another look at the udev rules on your test system? The last
> rule in 60-block.rules looks like a watch rule to me. The same holds for the
> upstream version of that file
> (https://github.com/systemd/systemd/blob/maste
> r/rules/60-block.rules).
>
> Bart.

It is a watch rule.

systemd/src/udev/udevd.c
   manager_new
       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

This rule ends up calling BLKRRPART.

Thanks,
Don Brace
ESC - Smart Storage
Microsemi Corporation


Is there more information that I can provide?





[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