Loading Documentation/feature-removal-schedule.txt +22 −0 Original line number Original line Diff line number Diff line Loading @@ -308,9 +308,31 @@ Who: Matthew Wilcox <willy@linux.intel.com> --------------------------- --------------------------- What: SCTP_GET_PEER_ADDRS_NUM_OLD, SCTP_GET_PEER_ADDRS_OLD, SCTP_GET_LOCAL_ADDRS_NUM_OLD, SCTP_GET_LOCAL_ADDRS_OLD When: June 2009 Why: A newer version of the options have been introduced in 2005 that removes the limitions of the old API. The sctp library has been converted to use these new options at the same time. Any user space app that directly uses the old options should convert to using the new options. Who: Vlad Yasevich <vladislav.yasevich@hp.com> --------------------------- What: CONFIG_THERMAL_HWMON What: CONFIG_THERMAL_HWMON When: January 2009 When: January 2009 Why: This option was introduced just to allow older lm-sensors userspace Why: This option was introduced just to allow older lm-sensors userspace to keep working over the upgrade to 2.6.26. At the scheduled time of to keep working over the upgrade to 2.6.26. At the scheduled time of removal fixed lm-sensors (2.x or 3.x) should be readily available. removal fixed lm-sensors (2.x or 3.x) should be readily available. Who: Rene Herman <rene.herman@gmail.com> Who: Rene Herman <rene.herman@gmail.com> --------------------------- What: Code that is now under CONFIG_WIRELESS_EXT_SYSFS (in net/core/net-sysfs.c) When: After the only user (hal) has seen a release with the patches for enough time, probably some time in 2010. Why: Over 1K .text/.data size reduction, data is available in other ways (ioctls) Who: Johannes Berg <johannes@sipsolutions.net> Documentation/filesystems/configfs/configfs.txt +4 −6 Original line number Original line Diff line number Diff line Loading @@ -233,12 +233,10 @@ accomplished via the group operations specified on the group's config_item_type. config_item_type. struct configfs_group_operations { struct configfs_group_operations { int (*make_item)(struct config_group *group, struct config_item *(*make_item)(struct config_group *group, const char *name, const char *name); struct config_item **new_item); struct config_group *(*make_group)(struct config_group *group, int (*make_group)(struct config_group *group, const char *name); const char *name, struct config_group **new_group); int (*commit_item)(struct config_item *item); int (*commit_item)(struct config_item *item); void (*disconnect_notify)(struct config_group *group, void (*disconnect_notify)(struct config_group *group, struct config_item *item); struct config_item *item); Loading Documentation/filesystems/configfs/configfs_example.c +6 −8 Original line number Original line Diff line number Diff line Loading @@ -273,13 +273,13 @@ static inline struct simple_children *to_simple_children(struct config_item *ite return item ? container_of(to_config_group(item), struct simple_children, group) : NULL; return item ? container_of(to_config_group(item), struct simple_children, group) : NULL; } } static int simple_children_make_item(struct config_group *group, const char *name, struct config_item **new_item) static struct config_item *simple_children_make_item(struct config_group *group, const char *name) { { struct simple_child *simple_child; struct simple_child *simple_child; simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL); simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL); if (!simple_child) if (!simple_child) return -ENOMEM; return ERR_PTR(-ENOMEM); config_item_init_type_name(&simple_child->item, name, config_item_init_type_name(&simple_child->item, name, Loading @@ -287,8 +287,7 @@ static int simple_children_make_item(struct config_group *group, const char *nam simple_child->storeme = 0; simple_child->storeme = 0; *new_item = &simple_child->item; return &simple_child->item; return 0; } } static struct configfs_attribute simple_children_attr_description = { static struct configfs_attribute simple_children_attr_description = { Loading Loading @@ -360,21 +359,20 @@ static struct configfs_subsystem simple_children_subsys = { * children of its own. * children of its own. */ */ static int group_children_make_group(struct config_group *group, const char *name, struct config_group **new_group) static struct config_group *group_children_make_group(struct config_group *group, const char *name) { { struct simple_children *simple_children; struct simple_children *simple_children; simple_children = kzalloc(sizeof(struct simple_children), simple_children = kzalloc(sizeof(struct simple_children), GFP_KERNEL); GFP_KERNEL); if (!simple_children) if (!simple_children) return -ENOMEM; return ERR_PTR(-ENOMEM); config_group_init_type_name(&simple_children->group, name, config_group_init_type_name(&simple_children->group, name, &simple_children_type); &simple_children_type); *new_group = &simple_children->group; return &simple_children->group; return 0; } } static struct configfs_attribute group_children_attr_description = { static struct configfs_attribute group_children_attr_description = { Loading Documentation/filesystems/nfs-rdma.txt +59 −44 Original line number Original line Diff line number Diff line Loading @@ -5,7 +5,7 @@ ################################################################################ ################################################################################ Author: NetApp and Open Grid Computing Author: NetApp and Open Grid Computing Date: April 15, 2008 Date: May 29, 2008 Table of Contents Table of Contents ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~ Loading Loading @@ -60,16 +60,18 @@ Installation The procedures described in this document have been tested with The procedures described in this document have been tested with distributions from Red Hat's Fedora Project (http://fedora.redhat.com/). distributions from Red Hat's Fedora Project (http://fedora.redhat.com/). - Install nfs-utils-1.1.1 or greater on the client - Install nfs-utils-1.1.2 or greater on the client An NFS/RDMA mount point can only be obtained by using the mount.nfs An NFS/RDMA mount point can be obtained by using the mount.nfs command in command in nfs-utils-1.1.1 or greater. To see which version of mount.nfs nfs-utils-1.1.2 or greater (nfs-utils-1.1.1 was the first nfs-utils you are using, type: version with support for NFS/RDMA mounts, but for various reasons we recommend using nfs-utils-1.1.2 or greater). To see which version of mount.nfs you are using, type: > /sbin/mount.nfs -V $ /sbin/mount.nfs -V If the version is less than 1.1.1 or the command does not exist, If the version is less than 1.1.2 or the command does not exist, then you will need to install the latest version of nfs-utils. you should install the latest version of nfs-utils. Download the latest package from: Download the latest package from: Loading @@ -77,22 +79,33 @@ Installation Uncompress the package and follow the installation instructions. Uncompress the package and follow the installation instructions. If you will not be using GSS and NFSv4, the installation process If you will not need the idmapper and gssd executables (you do not need can be simplified by disabling these features when running configure: these to create an NFS/RDMA enabled mount command), the installation process can be simplified by disabling these features when running configure: > ./configure --disable-gss --disable-nfsv4 $ ./configure --disable-gss --disable-nfsv4 For more information on this see the package's README and INSTALL files. To build nfs-utils you will need the tcp_wrappers package installed. For more information on this see the package's README and INSTALL files. After building the nfs-utils package, there will be a mount.nfs binary in After building the nfs-utils package, there will be a mount.nfs binary in the utils/mount directory. This binary can be used to initiate NFS v2, v3, the utils/mount directory. This binary can be used to initiate NFS v2, v3, or v4 mounts. To initiate a v4 mount, the binary must be called mount.nfs4. or v4 mounts. To initiate a v4 mount, the binary must be called The standard technique is to create a symlink called mount.nfs4 to mount.nfs. mount.nfs4. The standard technique is to create a symlink called mount.nfs4 to mount.nfs. NOTE: mount.nfs and therefore nfs-utils-1.1.1 or greater is only needed This mount.nfs binary should be installed at /sbin/mount.nfs as follows: $ sudo cp utils/mount/mount.nfs /sbin/mount.nfs In this location, mount.nfs will be invoked automatically for NFS mounts by the system mount commmand. NOTE: mount.nfs and therefore nfs-utils-1.1.2 or greater is only needed on the NFS client machine. You do not need this specific version of on the NFS client machine. You do not need this specific version of nfs-utils on the server. Furthermore, only the mount.nfs command from nfs-utils on the server. Furthermore, only the mount.nfs command from nfs-utils-1.1.1 is needed on the client. nfs-utils-1.1.2 is needed on the client. - Install a Linux kernel with NFS/RDMA - Install a Linux kernel with NFS/RDMA Loading Loading @@ -156,8 +169,8 @@ Check RDMA and NFS Setup this time. For example, if you are using a Mellanox Tavor/Sinai/Arbel this time. For example, if you are using a Mellanox Tavor/Sinai/Arbel card: card: > modprobe ib_mthca $ modprobe ib_mthca > modprobe ib_ipoib $ modprobe ib_ipoib If you are using InfiniBand, make sure there is a Subnet Manager (SM) If you are using InfiniBand, make sure there is a Subnet Manager (SM) running on the network. If your IB switch has an embedded SM, you can running on the network. If your IB switch has an embedded SM, you can Loading @@ -166,7 +179,7 @@ Check RDMA and NFS Setup If an SM is running on your network, you should see the following: If an SM is running on your network, you should see the following: > cat /sys/class/infiniband/driverX/ports/1/state $ cat /sys/class/infiniband/driverX/ports/1/state 4: ACTIVE 4: ACTIVE where driverX is mthca0, ipath5, ehca3, etc. where driverX is mthca0, ipath5, ehca3, etc. Loading @@ -174,10 +187,10 @@ Check RDMA and NFS Setup To further test the InfiniBand software stack, use IPoIB (this To further test the InfiniBand software stack, use IPoIB (this assumes you have two IB hosts named host1 and host2): assumes you have two IB hosts named host1 and host2): host1> ifconfig ib0 a.b.c.x host1$ ifconfig ib0 a.b.c.x host2> ifconfig ib0 a.b.c.y host2$ ifconfig ib0 a.b.c.y host1> ping a.b.c.y host1$ ping a.b.c.y host2> ping a.b.c.x host2$ ping a.b.c.x For other device types, follow the appropriate procedures. For other device types, follow the appropriate procedures. Loading @@ -202,11 +215,11 @@ NFS/RDMA Setup /vol0 192.168.0.47(fsid=0,rw,async,insecure,no_root_squash) /vol0 192.168.0.47(fsid=0,rw,async,insecure,no_root_squash) /vol0 192.168.0.0/255.255.255.0(fsid=0,rw,async,insecure,no_root_squash) /vol0 192.168.0.0/255.255.255.0(fsid=0,rw,async,insecure,no_root_squash) The IP address(es) is(are) the client's IPoIB address for an InfiniBand HCA or the The IP address(es) is(are) the client's IPoIB address for an InfiniBand cleint's iWARP address(es) for an RNIC. HCA or the cleint's iWARP address(es) for an RNIC. NOTE: The "insecure" option must be used because the NFS/RDMA client does not NOTE: The "insecure" option must be used because the NFS/RDMA client does use a reserved port. not use a reserved port. Each time a machine boots: Each time a machine boots: Loading @@ -214,43 +227,45 @@ NFS/RDMA Setup For InfiniBand using a Mellanox adapter: For InfiniBand using a Mellanox adapter: > modprobe ib_mthca $ modprobe ib_mthca > modprobe ib_ipoib $ modprobe ib_ipoib > ifconfig ib0 a.b.c.d $ ifconfig ib0 a.b.c.d NOTE: use unique addresses for the client and server NOTE: use unique addresses for the client and server - Start the NFS server - Start the NFS server If the NFS/RDMA server was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in kernel config), If the NFS/RDMA server was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in load the RDMA transport module: kernel config), load the RDMA transport module: > modprobe svcrdma $ modprobe svcrdma Regardless of how the server was built (module or built-in), start the server: Regardless of how the server was built (module or built-in), start the server: > /etc/init.d/nfs start $ /etc/init.d/nfs start or or > service nfs start $ service nfs start Instruct the server to listen on the RDMA transport: Instruct the server to listen on the RDMA transport: > echo rdma 2050 > /proc/fs/nfsd/portlist $ echo rdma 2050 > /proc/fs/nfsd/portlist - On the client system - On the client system If the NFS/RDMA client was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in kernel config), If the NFS/RDMA client was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in load the RDMA client module: kernel config), load the RDMA client module: > modprobe xprtrdma.ko $ modprobe xprtrdma.ko Regardless of how the client was built (module or built-in), issue the mount.nfs command: Regardless of how the client was built (module or built-in), use this command to mount the NFS/RDMA server: > /path/to/your/mount.nfs <IPoIB-server-name-or-address>:/<export> /mnt -i -o rdma,port=2050 $ mount -o rdma,port=2050 <IPoIB-server-name-or-address>:/<export> /mnt To verify that the mount is using RDMA, run "cat /proc/mounts" and check the To verify that the mount is using RDMA, run "cat /proc/mounts" and check "proto" field for the given mount. the "proto" field for the given mount. Congratulations! You're using NFS/RDMA! Congratulations! You're using NFS/RDMA! Documentation/networking/bonding.txt +80 −30 Original line number Original line Diff line number Diff line Loading @@ -289,35 +289,73 @@ downdelay fail_over_mac fail_over_mac Specifies whether active-backup mode should set all slaves to Specifies whether active-backup mode should set all slaves to the same MAC address (the traditional behavior), or, when the same MAC address at enslavement (the traditional enabled, change the bond's MAC address when changing the behavior), or, when enabled, perform special handling of the active interface (i.e., fail over the MAC address itself). bond's MAC address in accordance with the selected policy. Fail over MAC is useful for devices that cannot ever alter Possible values are: their MAC address, or for devices that refuse incoming broadcasts with their own source MAC (which interferes with none or 0 the ARP monitor). This setting disables fail_over_mac, and causes The down side of fail over MAC is that every device on the bonding to set all slaves of an active-backup bond to network must be updated via gratuitous ARP, vs. just updating the same MAC address at enslavement time. This is the a switch or set of switches (which often takes place for any default. traffic, not just ARP traffic, if the switch snoops incoming traffic to update its tables) for the traditional method. If active or 1 the gratuitous ARP is lost, communication may be disrupted. The "active" fail_over_mac policy indicates that the When fail over MAC is used in conjuction with the mii monitor, MAC address of the bond should always be the MAC devices which assert link up prior to being able to actually address of the currently active slave. The MAC transmit and receive are particularly susecptible to loss of address of the slaves is not changed; instead, the MAC the gratuitous ARP, and an appropriate updelay setting may be address of the bond changes during a failover. required. This policy is useful for devices that cannot ever A value of 0 disables fail over MAC, and is the default. A alter their MAC address, or for devices that refuse value of 1 enables fail over MAC. This option is enabled incoming broadcasts with their own source MAC (which automatically if the first slave added cannot change its MAC interferes with the ARP monitor). address. This option may be modified via sysfs only when no slaves are present in the bond. The down side of this policy is that every device on the network must be updated via gratuitous ARP, This option was added in bonding version 3.2.0. vs. just updating a switch or set of switches (which often takes place for any traffic, not just ARP traffic, if the switch snoops incoming traffic to update its tables) for the traditional method. If the gratuitous ARP is lost, communication may be disrupted. When this policy is used in conjuction with the mii monitor, devices which assert link up prior to being able to actually transmit and receive are particularly susecptible to loss of the gratuitous ARP, and an appropriate updelay setting may be required. follow or 2 The "follow" fail_over_mac policy causes the MAC address of the bond to be selected normally (normally the MAC address of the first slave added to the bond). However, the second and subsequent slaves are not set to this MAC address while they are in a backup role; a slave is programmed with the bond's MAC address at failover time (and the formerly active slave receives the newly active slave's MAC address). This policy is useful for multiport devices that either become confused or incur a performance penalty when multiple ports are programmed with the same MAC address. The default policy is none, unless the first slave cannot change its MAC address, in which case the active policy is selected by default. This option may be modified via sysfs only when no slaves are present in the bond. This option was added in bonding version 3.2.0. The "follow" policy was added in bonding version 3.3.0. lacp_rate lacp_rate Loading @@ -338,7 +376,8 @@ max_bonds Specifies the number of bonding devices to create for this Specifies the number of bonding devices to create for this instance of the bonding driver. E.g., if max_bonds is 3, and instance of the bonding driver. E.g., if max_bonds is 3, and the bonding driver is not already loaded, then bond0, bond1 the bonding driver is not already loaded, then bond0, bond1 and bond2 will be created. The default value is 1. and bond2 will be created. The default value is 1. Specifying a value of 0 will load bonding, but will not create any devices. miimon miimon Loading Loading @@ -501,6 +540,17 @@ mode swapped with the new curr_active_slave that was swapped with the new curr_active_slave that was chosen. chosen. num_grat_arp Specifies the number of gratuitous ARPs to be issued after a failover event. One gratuitous ARP is issued immediately after the failover, subsequent ARPs are sent at a rate of one per link monitor interval (arp_interval or miimon, whichever is active). The valid range is 0 - 255; the default value is 1. This option affects only the active-backup mode. This option was added for bonding version 3.3.0. primary primary A string (eth0, eth2, etc) specifying which slave is the A string (eth0, eth2, etc) specifying which slave is the Loading Loading
Documentation/feature-removal-schedule.txt +22 −0 Original line number Original line Diff line number Diff line Loading @@ -308,9 +308,31 @@ Who: Matthew Wilcox <willy@linux.intel.com> --------------------------- --------------------------- What: SCTP_GET_PEER_ADDRS_NUM_OLD, SCTP_GET_PEER_ADDRS_OLD, SCTP_GET_LOCAL_ADDRS_NUM_OLD, SCTP_GET_LOCAL_ADDRS_OLD When: June 2009 Why: A newer version of the options have been introduced in 2005 that removes the limitions of the old API. The sctp library has been converted to use these new options at the same time. Any user space app that directly uses the old options should convert to using the new options. Who: Vlad Yasevich <vladislav.yasevich@hp.com> --------------------------- What: CONFIG_THERMAL_HWMON What: CONFIG_THERMAL_HWMON When: January 2009 When: January 2009 Why: This option was introduced just to allow older lm-sensors userspace Why: This option was introduced just to allow older lm-sensors userspace to keep working over the upgrade to 2.6.26. At the scheduled time of to keep working over the upgrade to 2.6.26. At the scheduled time of removal fixed lm-sensors (2.x or 3.x) should be readily available. removal fixed lm-sensors (2.x or 3.x) should be readily available. Who: Rene Herman <rene.herman@gmail.com> Who: Rene Herman <rene.herman@gmail.com> --------------------------- What: Code that is now under CONFIG_WIRELESS_EXT_SYSFS (in net/core/net-sysfs.c) When: After the only user (hal) has seen a release with the patches for enough time, probably some time in 2010. Why: Over 1K .text/.data size reduction, data is available in other ways (ioctls) Who: Johannes Berg <johannes@sipsolutions.net>
Documentation/filesystems/configfs/configfs.txt +4 −6 Original line number Original line Diff line number Diff line Loading @@ -233,12 +233,10 @@ accomplished via the group operations specified on the group's config_item_type. config_item_type. struct configfs_group_operations { struct configfs_group_operations { int (*make_item)(struct config_group *group, struct config_item *(*make_item)(struct config_group *group, const char *name, const char *name); struct config_item **new_item); struct config_group *(*make_group)(struct config_group *group, int (*make_group)(struct config_group *group, const char *name); const char *name, struct config_group **new_group); int (*commit_item)(struct config_item *item); int (*commit_item)(struct config_item *item); void (*disconnect_notify)(struct config_group *group, void (*disconnect_notify)(struct config_group *group, struct config_item *item); struct config_item *item); Loading
Documentation/filesystems/configfs/configfs_example.c +6 −8 Original line number Original line Diff line number Diff line Loading @@ -273,13 +273,13 @@ static inline struct simple_children *to_simple_children(struct config_item *ite return item ? container_of(to_config_group(item), struct simple_children, group) : NULL; return item ? container_of(to_config_group(item), struct simple_children, group) : NULL; } } static int simple_children_make_item(struct config_group *group, const char *name, struct config_item **new_item) static struct config_item *simple_children_make_item(struct config_group *group, const char *name) { { struct simple_child *simple_child; struct simple_child *simple_child; simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL); simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL); if (!simple_child) if (!simple_child) return -ENOMEM; return ERR_PTR(-ENOMEM); config_item_init_type_name(&simple_child->item, name, config_item_init_type_name(&simple_child->item, name, Loading @@ -287,8 +287,7 @@ static int simple_children_make_item(struct config_group *group, const char *nam simple_child->storeme = 0; simple_child->storeme = 0; *new_item = &simple_child->item; return &simple_child->item; return 0; } } static struct configfs_attribute simple_children_attr_description = { static struct configfs_attribute simple_children_attr_description = { Loading Loading @@ -360,21 +359,20 @@ static struct configfs_subsystem simple_children_subsys = { * children of its own. * children of its own. */ */ static int group_children_make_group(struct config_group *group, const char *name, struct config_group **new_group) static struct config_group *group_children_make_group(struct config_group *group, const char *name) { { struct simple_children *simple_children; struct simple_children *simple_children; simple_children = kzalloc(sizeof(struct simple_children), simple_children = kzalloc(sizeof(struct simple_children), GFP_KERNEL); GFP_KERNEL); if (!simple_children) if (!simple_children) return -ENOMEM; return ERR_PTR(-ENOMEM); config_group_init_type_name(&simple_children->group, name, config_group_init_type_name(&simple_children->group, name, &simple_children_type); &simple_children_type); *new_group = &simple_children->group; return &simple_children->group; return 0; } } static struct configfs_attribute group_children_attr_description = { static struct configfs_attribute group_children_attr_description = { Loading
Documentation/filesystems/nfs-rdma.txt +59 −44 Original line number Original line Diff line number Diff line Loading @@ -5,7 +5,7 @@ ################################################################################ ################################################################################ Author: NetApp and Open Grid Computing Author: NetApp and Open Grid Computing Date: April 15, 2008 Date: May 29, 2008 Table of Contents Table of Contents ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~ Loading Loading @@ -60,16 +60,18 @@ Installation The procedures described in this document have been tested with The procedures described in this document have been tested with distributions from Red Hat's Fedora Project (http://fedora.redhat.com/). distributions from Red Hat's Fedora Project (http://fedora.redhat.com/). - Install nfs-utils-1.1.1 or greater on the client - Install nfs-utils-1.1.2 or greater on the client An NFS/RDMA mount point can only be obtained by using the mount.nfs An NFS/RDMA mount point can be obtained by using the mount.nfs command in command in nfs-utils-1.1.1 or greater. To see which version of mount.nfs nfs-utils-1.1.2 or greater (nfs-utils-1.1.1 was the first nfs-utils you are using, type: version with support for NFS/RDMA mounts, but for various reasons we recommend using nfs-utils-1.1.2 or greater). To see which version of mount.nfs you are using, type: > /sbin/mount.nfs -V $ /sbin/mount.nfs -V If the version is less than 1.1.1 or the command does not exist, If the version is less than 1.1.2 or the command does not exist, then you will need to install the latest version of nfs-utils. you should install the latest version of nfs-utils. Download the latest package from: Download the latest package from: Loading @@ -77,22 +79,33 @@ Installation Uncompress the package and follow the installation instructions. Uncompress the package and follow the installation instructions. If you will not be using GSS and NFSv4, the installation process If you will not need the idmapper and gssd executables (you do not need can be simplified by disabling these features when running configure: these to create an NFS/RDMA enabled mount command), the installation process can be simplified by disabling these features when running configure: > ./configure --disable-gss --disable-nfsv4 $ ./configure --disable-gss --disable-nfsv4 For more information on this see the package's README and INSTALL files. To build nfs-utils you will need the tcp_wrappers package installed. For more information on this see the package's README and INSTALL files. After building the nfs-utils package, there will be a mount.nfs binary in After building the nfs-utils package, there will be a mount.nfs binary in the utils/mount directory. This binary can be used to initiate NFS v2, v3, the utils/mount directory. This binary can be used to initiate NFS v2, v3, or v4 mounts. To initiate a v4 mount, the binary must be called mount.nfs4. or v4 mounts. To initiate a v4 mount, the binary must be called The standard technique is to create a symlink called mount.nfs4 to mount.nfs. mount.nfs4. The standard technique is to create a symlink called mount.nfs4 to mount.nfs. NOTE: mount.nfs and therefore nfs-utils-1.1.1 or greater is only needed This mount.nfs binary should be installed at /sbin/mount.nfs as follows: $ sudo cp utils/mount/mount.nfs /sbin/mount.nfs In this location, mount.nfs will be invoked automatically for NFS mounts by the system mount commmand. NOTE: mount.nfs and therefore nfs-utils-1.1.2 or greater is only needed on the NFS client machine. You do not need this specific version of on the NFS client machine. You do not need this specific version of nfs-utils on the server. Furthermore, only the mount.nfs command from nfs-utils on the server. Furthermore, only the mount.nfs command from nfs-utils-1.1.1 is needed on the client. nfs-utils-1.1.2 is needed on the client. - Install a Linux kernel with NFS/RDMA - Install a Linux kernel with NFS/RDMA Loading Loading @@ -156,8 +169,8 @@ Check RDMA and NFS Setup this time. For example, if you are using a Mellanox Tavor/Sinai/Arbel this time. For example, if you are using a Mellanox Tavor/Sinai/Arbel card: card: > modprobe ib_mthca $ modprobe ib_mthca > modprobe ib_ipoib $ modprobe ib_ipoib If you are using InfiniBand, make sure there is a Subnet Manager (SM) If you are using InfiniBand, make sure there is a Subnet Manager (SM) running on the network. If your IB switch has an embedded SM, you can running on the network. If your IB switch has an embedded SM, you can Loading @@ -166,7 +179,7 @@ Check RDMA and NFS Setup If an SM is running on your network, you should see the following: If an SM is running on your network, you should see the following: > cat /sys/class/infiniband/driverX/ports/1/state $ cat /sys/class/infiniband/driverX/ports/1/state 4: ACTIVE 4: ACTIVE where driverX is mthca0, ipath5, ehca3, etc. where driverX is mthca0, ipath5, ehca3, etc. Loading @@ -174,10 +187,10 @@ Check RDMA and NFS Setup To further test the InfiniBand software stack, use IPoIB (this To further test the InfiniBand software stack, use IPoIB (this assumes you have two IB hosts named host1 and host2): assumes you have two IB hosts named host1 and host2): host1> ifconfig ib0 a.b.c.x host1$ ifconfig ib0 a.b.c.x host2> ifconfig ib0 a.b.c.y host2$ ifconfig ib0 a.b.c.y host1> ping a.b.c.y host1$ ping a.b.c.y host2> ping a.b.c.x host2$ ping a.b.c.x For other device types, follow the appropriate procedures. For other device types, follow the appropriate procedures. Loading @@ -202,11 +215,11 @@ NFS/RDMA Setup /vol0 192.168.0.47(fsid=0,rw,async,insecure,no_root_squash) /vol0 192.168.0.47(fsid=0,rw,async,insecure,no_root_squash) /vol0 192.168.0.0/255.255.255.0(fsid=0,rw,async,insecure,no_root_squash) /vol0 192.168.0.0/255.255.255.0(fsid=0,rw,async,insecure,no_root_squash) The IP address(es) is(are) the client's IPoIB address for an InfiniBand HCA or the The IP address(es) is(are) the client's IPoIB address for an InfiniBand cleint's iWARP address(es) for an RNIC. HCA or the cleint's iWARP address(es) for an RNIC. NOTE: The "insecure" option must be used because the NFS/RDMA client does not NOTE: The "insecure" option must be used because the NFS/RDMA client does use a reserved port. not use a reserved port. Each time a machine boots: Each time a machine boots: Loading @@ -214,43 +227,45 @@ NFS/RDMA Setup For InfiniBand using a Mellanox adapter: For InfiniBand using a Mellanox adapter: > modprobe ib_mthca $ modprobe ib_mthca > modprobe ib_ipoib $ modprobe ib_ipoib > ifconfig ib0 a.b.c.d $ ifconfig ib0 a.b.c.d NOTE: use unique addresses for the client and server NOTE: use unique addresses for the client and server - Start the NFS server - Start the NFS server If the NFS/RDMA server was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in kernel config), If the NFS/RDMA server was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in load the RDMA transport module: kernel config), load the RDMA transport module: > modprobe svcrdma $ modprobe svcrdma Regardless of how the server was built (module or built-in), start the server: Regardless of how the server was built (module or built-in), start the server: > /etc/init.d/nfs start $ /etc/init.d/nfs start or or > service nfs start $ service nfs start Instruct the server to listen on the RDMA transport: Instruct the server to listen on the RDMA transport: > echo rdma 2050 > /proc/fs/nfsd/portlist $ echo rdma 2050 > /proc/fs/nfsd/portlist - On the client system - On the client system If the NFS/RDMA client was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in kernel config), If the NFS/RDMA client was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in load the RDMA client module: kernel config), load the RDMA client module: > modprobe xprtrdma.ko $ modprobe xprtrdma.ko Regardless of how the client was built (module or built-in), issue the mount.nfs command: Regardless of how the client was built (module or built-in), use this command to mount the NFS/RDMA server: > /path/to/your/mount.nfs <IPoIB-server-name-or-address>:/<export> /mnt -i -o rdma,port=2050 $ mount -o rdma,port=2050 <IPoIB-server-name-or-address>:/<export> /mnt To verify that the mount is using RDMA, run "cat /proc/mounts" and check the To verify that the mount is using RDMA, run "cat /proc/mounts" and check "proto" field for the given mount. the "proto" field for the given mount. Congratulations! You're using NFS/RDMA! Congratulations! You're using NFS/RDMA!
Documentation/networking/bonding.txt +80 −30 Original line number Original line Diff line number Diff line Loading @@ -289,35 +289,73 @@ downdelay fail_over_mac fail_over_mac Specifies whether active-backup mode should set all slaves to Specifies whether active-backup mode should set all slaves to the same MAC address (the traditional behavior), or, when the same MAC address at enslavement (the traditional enabled, change the bond's MAC address when changing the behavior), or, when enabled, perform special handling of the active interface (i.e., fail over the MAC address itself). bond's MAC address in accordance with the selected policy. Fail over MAC is useful for devices that cannot ever alter Possible values are: their MAC address, or for devices that refuse incoming broadcasts with their own source MAC (which interferes with none or 0 the ARP monitor). This setting disables fail_over_mac, and causes The down side of fail over MAC is that every device on the bonding to set all slaves of an active-backup bond to network must be updated via gratuitous ARP, vs. just updating the same MAC address at enslavement time. This is the a switch or set of switches (which often takes place for any default. traffic, not just ARP traffic, if the switch snoops incoming traffic to update its tables) for the traditional method. If active or 1 the gratuitous ARP is lost, communication may be disrupted. The "active" fail_over_mac policy indicates that the When fail over MAC is used in conjuction with the mii monitor, MAC address of the bond should always be the MAC devices which assert link up prior to being able to actually address of the currently active slave. The MAC transmit and receive are particularly susecptible to loss of address of the slaves is not changed; instead, the MAC the gratuitous ARP, and an appropriate updelay setting may be address of the bond changes during a failover. required. This policy is useful for devices that cannot ever A value of 0 disables fail over MAC, and is the default. A alter their MAC address, or for devices that refuse value of 1 enables fail over MAC. This option is enabled incoming broadcasts with their own source MAC (which automatically if the first slave added cannot change its MAC interferes with the ARP monitor). address. This option may be modified via sysfs only when no slaves are present in the bond. The down side of this policy is that every device on the network must be updated via gratuitous ARP, This option was added in bonding version 3.2.0. vs. just updating a switch or set of switches (which often takes place for any traffic, not just ARP traffic, if the switch snoops incoming traffic to update its tables) for the traditional method. If the gratuitous ARP is lost, communication may be disrupted. When this policy is used in conjuction with the mii monitor, devices which assert link up prior to being able to actually transmit and receive are particularly susecptible to loss of the gratuitous ARP, and an appropriate updelay setting may be required. follow or 2 The "follow" fail_over_mac policy causes the MAC address of the bond to be selected normally (normally the MAC address of the first slave added to the bond). However, the second and subsequent slaves are not set to this MAC address while they are in a backup role; a slave is programmed with the bond's MAC address at failover time (and the formerly active slave receives the newly active slave's MAC address). This policy is useful for multiport devices that either become confused or incur a performance penalty when multiple ports are programmed with the same MAC address. The default policy is none, unless the first slave cannot change its MAC address, in which case the active policy is selected by default. This option may be modified via sysfs only when no slaves are present in the bond. This option was added in bonding version 3.2.0. The "follow" policy was added in bonding version 3.3.0. lacp_rate lacp_rate Loading @@ -338,7 +376,8 @@ max_bonds Specifies the number of bonding devices to create for this Specifies the number of bonding devices to create for this instance of the bonding driver. E.g., if max_bonds is 3, and instance of the bonding driver. E.g., if max_bonds is 3, and the bonding driver is not already loaded, then bond0, bond1 the bonding driver is not already loaded, then bond0, bond1 and bond2 will be created. The default value is 1. and bond2 will be created. The default value is 1. Specifying a value of 0 will load bonding, but will not create any devices. miimon miimon Loading Loading @@ -501,6 +540,17 @@ mode swapped with the new curr_active_slave that was swapped with the new curr_active_slave that was chosen. chosen. num_grat_arp Specifies the number of gratuitous ARPs to be issued after a failover event. One gratuitous ARP is issued immediately after the failover, subsequent ARPs are sent at a rate of one per link monitor interval (arp_interval or miimon, whichever is active). The valid range is 0 - 255; the default value is 1. This option affects only the active-backup mode. This option was added for bonding version 3.3.0. primary primary A string (eth0, eth2, etc) specifying which slave is the A string (eth0, eth2, etc) specifying which slave is the Loading
