Archive-Team
/
zfs
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 103 Wiki Activity
zfs/scripts/zpool-config/dragon-raidz-7x10.sh

22 lines
474 B
Bash
Raw Normal View History

Update zpool-configs to be udev aware. To simplify creation and management of test configurations the dragon and x4550 configureis have been integrated with udev. Our current best guess as to how we'll actually manage the disks in these systems is with a udev mapping scheme. The current leading scheme is to map each drive to a simpe <CHANNEL><RANK> id. In this mapping each CHANNEL is represented by the letters a-z, and the RANK is represented by the numbers 1-n. A CHANNEL should identify a group of RANKS which are all attached to a single controller, each RANK represents a disk. This provides a nice mechanism to locate a specific drive given a known hardware configuration. Various hardware vendors use a similar scheme. A nice side effect of these changes is it allowed me to make the raid0/raid10/raidz/raidz2 setup functions generic. This makes adding new test configs easy, you just need to create a udev rules file for your test config which conforms to the naming scheme.
2009-10-21 18:38:51 +00:00
#!/bin/bash
#
# Dragon (White Box) Raid-Z Configuration (7x10(9+1))
#
RANKS=7
CHANNELS=10
zpool_create() {
Split the udev rule from a specific configuration While I completely agree the udev is the lesser of many possibles evils when solving the device issue... it is still evil. After attempting to craft a single rule which will work for various versions of udev in various distros. I've come to the conclusion the only maintainable way to solve this issue is to split the rule from any particular configuration. This commit provides a generic 60-zpool.rules file which use a small helper util 'zpool_id' to parse a configuration file by default located in /etc/zfs/zdev.conf. The helper script maps a by-path udev name to a more friendly name of <channel><rank> for large configurations. As part of this change all of the support scripts why rely on this udev naming convention have been updated as needed. Example zdev.conf files have also been added for 3 different systems by you will always need to add one for your exact hardware. Finally, included in these changes are the proper tweaks to the build system to ensure everything still get's packaged properly in the rpms and can run in or out of tree.
2010-03-02 00:45:31 +00:00
udev_setup ${ETCDIR}/zfs/zdev.conf.dragon.example
Update zpool-configs to be udev aware. To simplify creation and management of test configurations the dragon and x4550 configureis have been integrated with udev. Our current best guess as to how we'll actually manage the disks in these systems is with a udev mapping scheme. The current leading scheme is to map each drive to a simpe <CHANNEL><RANK> id. In this mapping each CHANNEL is represented by the letters a-z, and the RANK is represented by the numbers 1-n. A CHANNEL should identify a group of RANKS which are all attached to a single controller, each RANK represents a disk. This provides a nice mechanism to locate a specific drive given a known hardware configuration. Various hardware vendors use a similar scheme. A nice side effect of these changes is it allowed me to make the raid0/raid10/raidz/raidz2 setup functions generic. This makes adding new test configs easy, you just need to create a udev rules file for your test config which conforms to the naming scheme.
2009-10-21 18:38:51 +00:00
udev_raidz_setup ${RANKS} ${CHANNELS}
msg ${ZPOOL} create ${FORCE_FLAG} ${ZPOOL_NAME} ${RAIDZS[*]}
${ZPOOL} create ${FORCE_FLAG} ${ZPOOL_NAME} ${RAIDZS[*]} || exit 1
}
zpool_destroy() {
msg ${ZPOOL} destroy ${ZPOOL_NAME}
${ZPOOL} destroy ${ZPOOL_NAME}
Remove udev dependency when running in-tree After much contemplation I can't see a clean way to use udev entirely in-tree for testing. This patch removed a horrible horrible hack which would copy the needed udev bits in to place on your system to make it work. That however is simply not acceptable, nothing you in in-tree should ever ever ever install something on your system. Since I could not come up with a clean way to use udev in-tree. The fix is to simply parse the zdev config file and create the needed symlinks in a sub-diretory or your working tree. This is not as clean as using udev but it does work perfectly well for in-tree testing.
2010-03-11 21:56:20 +00:00
udev_cleanup ${ETCDIR}/zfs/zdev.conf.dragon.example
Update zpool-configs to be udev aware. To simplify creation and management of test configurations the dragon and x4550 configureis have been integrated with udev. Our current best guess as to how we'll actually manage the disks in these systems is with a udev mapping scheme. The current leading scheme is to map each drive to a simpe <CHANNEL><RANK> id. In this mapping each CHANNEL is represented by the letters a-z, and the RANK is represented by the numbers 1-n. A CHANNEL should identify a group of RANKS which are all attached to a single controller, each RANK represents a disk. This provides a nice mechanism to locate a specific drive given a known hardware configuration. Various hardware vendors use a similar scheme. A nice side effect of these changes is it allowed me to make the raid0/raid10/raidz/raidz2 setup functions generic. This makes adding new test configs easy, you just need to create a udev rules file for your test config which conforms to the naming scheme.
2009-10-21 18:38:51 +00:00
}