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

Re: Installer device Filtering...



Just a few comments from the viewpoint of the s390 architecture, which
could provide use cases since there are often many (hundreds or
thousands of) devices, as we have already discussed at FUDCon.

On 06/19/2009 01:49 PM, Joel Granados wrote:
>  * What information to give to the filter?  This is related to the UI.
>    And this was the reason to begin the discussion.
>    - Give a regular expression that identifies the devices

Regexes seem way too complicated for anaconda which otherwise guides the
user in a very helpful way. Wouldn't two entry fields to specify an
interval/range do it? I mean, on systems with many (hundreds to
thousands on s390) devices users would typically want to filter for
device number ranges. E.g. activate all DASDs between and including
0.0.beef and 0.0.dead.

>  * On what would those regular expressions operate?
>    - canonicalized path of the device link under /sys/block.
>    - []$ readlink -f /sys/block/sda/device
>      /sys/devices/pci0000:00/0000:00:05.0/host0/target0:0:0/0:0:0:0

# readlink -f /sys/block/dasda/device
/sys/devices/css0/0.0.0003/0.0.eb1b
# readlink -f /sys/block/sda/device
/sys/devices/css0/0.0.0015/0.0.3c1b/host0/rport-0:0-24/target0:0:24/0:0:24:1089355792

>    - /dev/disk/by-path version is also possible.  Could be useful.

/dev/disk/by-path/ccw-0.0.eb1b -> ../../dasda
/dev/disk/by-path/ccw-0.0.3c1b-zfcp-0x5005XXXXXXXXXXXXX:0xXXXXXXXX00000000
-> ../../sda

By-path looks less confusing but I don't know whether users would want
to filter for rport, target or other stuff in the canonicalized path.

>  * Why not have the possibility to refresh?  (Refresh would work with
>    the information contained in the kernel.)
>    - The user tweaks the scanning list and hits refresh.
>    - User does this until he/she is satisfied with the device list.
> 
>  * Three possible scanning stages where identified.  Each of these might
>    be controlled by the filter.
>    1. Kernel scan

On s390 we have a kernel command line option cio_ignore to prevent
devices from even being sensed by the kernel, since on systems with
thousands of devices already the pure sensing might consume too much
time or memory (for the allocated in-kernel device objects).

>    2. udev scan
>    3. devicetree.py:scan
> 
>  *  We actually want to be able to tell the kernel not to scan certain
>     LUN's.
> 
>  *  Wish people would learn how to configure fibrechannel switch acl's so we
>     would only see the lun's they actually want us to touch.  Would it
>     be a good idea to document the configuration setup that anaconda
>     expects?

On s390, only devices that have been sensed *and* are activated
explicitly become visible to Linux. I agree with Chris that we should
support all users no matter how they have configured their I/O
subsystem. Even if users have setup their FCP storage network with ACLs
but don't have NPIV in their hardware, they might see all disks of all
virtual machines on the system. Due to massive virtualization this means
n disks per VM times the number of VMs which might be hundreds and thus
too many devices.

Even if this might mean that s390 does not need additional device
filtering, it maybe advantageous to design it such that we can share
code between generic filtering and the display filtering of devices in
the advanced storage configuration subdialogs.

Steffen Maier

Linux on System z Development

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Erich Baier
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294



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