Loading Documentation/feature-removal-schedule.txt +22 −0 Original line number 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 When: January 2009 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 removal fixed lm-sensors (2.x or 3.x) should be readily available. 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 Diff line number Diff line Loading @@ -233,12 +233,10 @@ accomplished via the group operations specified on the group's config_item_type. struct configfs_group_operations { int (*make_item)(struct config_group *group, const char *name, struct config_item **new_item); int (*make_group)(struct config_group *group, const char *name, struct config_group **new_group); struct config_item *(*make_item)(struct config_group *group, const char *name); struct config_group *(*make_group)(struct config_group *group, const char *name); int (*commit_item)(struct config_item *item); void (*disconnect_notify)(struct config_group *group, struct config_item *item); Loading Documentation/filesystems/configfs/configfs_example.c +6 −8 Original line number 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; } 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; simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL); if (!simple_child) return -ENOMEM; return ERR_PTR(-ENOMEM); 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; *new_item = &simple_child->item; return 0; return &simple_child->item; } 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. */ 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; simple_children = kzalloc(sizeof(struct simple_children), GFP_KERNEL); if (!simple_children) return -ENOMEM; return ERR_PTR(-ENOMEM); config_group_init_type_name(&simple_children->group, name, &simple_children_type); *new_group = &simple_children->group; return 0; return &simple_children->group; } static struct configfs_attribute group_children_attr_description = { Loading Documentation/filesystems/nfs-rdma.txt +59 −44 Original line number Diff line number Diff line Loading @@ -5,7 +5,7 @@ ################################################################################ Author: NetApp and Open Grid Computing Date: April 15, 2008 Date: May 29, 2008 Table of Contents ~~~~~~~~~~~~~~~~~ Loading Loading @@ -60,16 +60,18 @@ Installation The procedures described in this document have been tested with 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 command in nfs-utils-1.1.1 or greater. To see which version of mount.nfs you are using, type: An NFS/RDMA mount point can be obtained by using the mount.nfs command in nfs-utils-1.1.2 or greater (nfs-utils-1.1.1 was the first nfs-utils 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, then you will need to install the latest version of nfs-utils. If the version is less than 1.1.2 or the command does not exist, you should install the latest version of nfs-utils. Download the latest package from: Loading @@ -77,22 +79,33 @@ Installation Uncompress the package and follow the installation instructions. If you will not be using GSS and NFSv4, the installation process can be simplified by disabling these features when running configure: If you will not need the idmapper and gssd executables (you do not need 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 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. The standard technique is to create a symlink called mount.nfs4 to mount.nfs. or v4 mounts. To initiate a v4 mount, the binary must be called 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 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 Loading Loading @@ -156,8 +169,8 @@ Check RDMA and NFS Setup this time. For example, if you are using a Mellanox Tavor/Sinai/Arbel card: > modprobe ib_mthca > modprobe ib_ipoib $ modprobe ib_mthca $ modprobe ib_ipoib 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 Loading @@ -166,7 +179,7 @@ Check RDMA and NFS Setup 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 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 assumes you have two IB hosts named host1 and host2): host1> ifconfig ib0 a.b.c.x host2> ifconfig ib0 a.b.c.y host1> ping a.b.c.y host2> ping a.b.c.x host1$ ifconfig ib0 a.b.c.x host2$ ifconfig ib0 a.b.c.y host1$ ping a.b.c.y host2$ ping a.b.c.x 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.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 cleint's iWARP address(es) for an RNIC. The IP address(es) is(are) the client's IPoIB address for an InfiniBand 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 use a reserved port. NOTE: The "insecure" option must be used because the NFS/RDMA client does not use a reserved port. Each time a machine boots: Loading @@ -214,43 +227,45 @@ NFS/RDMA Setup For InfiniBand using a Mellanox adapter: > modprobe ib_mthca > modprobe ib_ipoib > ifconfig ib0 a.b.c.d $ modprobe ib_mthca $ modprobe ib_ipoib $ ifconfig ib0 a.b.c.d NOTE: use unique addresses for the client and server - Start the NFS server If the NFS/RDMA server was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in kernel config), load the RDMA transport module: If the NFS/RDMA server was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in 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 > service nfs start $ service nfs start 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 If the NFS/RDMA client was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in kernel config), load the RDMA client module: If the NFS/RDMA client was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in 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 "proto" field for the given mount. To verify that the mount is using RDMA, run "cat /proc/mounts" and check the "proto" field for the given mount. Congratulations! You're using NFS/RDMA! Documentation/networking/bonding.txt +80 −30 Original line number Diff line number Diff line Loading @@ -289,35 +289,73 @@ downdelay fail_over_mac Specifies whether active-backup mode should set all slaves to the same MAC address (the traditional behavior), or, when enabled, change the bond's MAC address when changing the active interface (i.e., fail over the MAC address itself). Fail over MAC is useful for devices that cannot ever alter their MAC address, or for devices that refuse incoming broadcasts with their own source MAC (which interferes with the ARP monitor). The down side of fail over MAC is that every device on the network must be updated via gratuitous ARP, 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 fail over MAC 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. A value of 0 disables fail over MAC, and is the default. A value of 1 enables fail over MAC. This option is enabled automatically if the first slave added cannot change its MAC address. 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 same MAC address at enslavement (the traditional behavior), or, when enabled, perform special handling of the bond's MAC address in accordance with the selected policy. Possible values are: none or 0 This setting disables fail_over_mac, and causes bonding to set all slaves of an active-backup bond to the same MAC address at enslavement time. This is the default. active or 1 The "active" fail_over_mac policy indicates that the MAC address of the bond should always be the MAC address of the currently active slave. The MAC address of the slaves is not changed; instead, the MAC address of the bond changes during a failover. This policy is useful for devices that cannot ever alter their MAC address, or for devices that refuse incoming broadcasts with their own source MAC (which interferes with the ARP monitor). The down side of this policy is that every device on the network must be updated via gratuitous ARP, 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 Loading @@ -338,7 +376,8 @@ max_bonds Specifies the number of bonding devices to create for this instance of the bonding driver. E.g., if max_bonds is 3, and 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 Loading Loading @@ -501,6 +540,17 @@ mode swapped with the new curr_active_slave that was 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 A string (eth0, eth2, etc) specifying which slave is the Loading Loading
Documentation/feature-removal-schedule.txt +22 −0 Original line number 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 When: January 2009 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 removal fixed lm-sensors (2.x or 3.x) should be readily available. 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 Diff line number Diff line Loading @@ -233,12 +233,10 @@ accomplished via the group operations specified on the group's config_item_type. struct configfs_group_operations { int (*make_item)(struct config_group *group, const char *name, struct config_item **new_item); int (*make_group)(struct config_group *group, const char *name, struct config_group **new_group); struct config_item *(*make_item)(struct config_group *group, const char *name); struct config_group *(*make_group)(struct config_group *group, const char *name); int (*commit_item)(struct config_item *item); void (*disconnect_notify)(struct config_group *group, struct config_item *item); Loading
Documentation/filesystems/configfs/configfs_example.c +6 −8 Original line number 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; } 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; simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL); if (!simple_child) return -ENOMEM; return ERR_PTR(-ENOMEM); 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; *new_item = &simple_child->item; return 0; return &simple_child->item; } 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. */ 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; simple_children = kzalloc(sizeof(struct simple_children), GFP_KERNEL); if (!simple_children) return -ENOMEM; return ERR_PTR(-ENOMEM); config_group_init_type_name(&simple_children->group, name, &simple_children_type); *new_group = &simple_children->group; return 0; return &simple_children->group; } static struct configfs_attribute group_children_attr_description = { Loading
Documentation/filesystems/nfs-rdma.txt +59 −44 Original line number Diff line number Diff line Loading @@ -5,7 +5,7 @@ ################################################################################ Author: NetApp and Open Grid Computing Date: April 15, 2008 Date: May 29, 2008 Table of Contents ~~~~~~~~~~~~~~~~~ Loading Loading @@ -60,16 +60,18 @@ Installation The procedures described in this document have been tested with 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 command in nfs-utils-1.1.1 or greater. To see which version of mount.nfs you are using, type: An NFS/RDMA mount point can be obtained by using the mount.nfs command in nfs-utils-1.1.2 or greater (nfs-utils-1.1.1 was the first nfs-utils 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, then you will need to install the latest version of nfs-utils. If the version is less than 1.1.2 or the command does not exist, you should install the latest version of nfs-utils. Download the latest package from: Loading @@ -77,22 +79,33 @@ Installation Uncompress the package and follow the installation instructions. If you will not be using GSS and NFSv4, the installation process can be simplified by disabling these features when running configure: If you will not need the idmapper and gssd executables (you do not need 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 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. The standard technique is to create a symlink called mount.nfs4 to mount.nfs. or v4 mounts. To initiate a v4 mount, the binary must be called 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 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 Loading Loading @@ -156,8 +169,8 @@ Check RDMA and NFS Setup this time. For example, if you are using a Mellanox Tavor/Sinai/Arbel card: > modprobe ib_mthca > modprobe ib_ipoib $ modprobe ib_mthca $ modprobe ib_ipoib 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 Loading @@ -166,7 +179,7 @@ Check RDMA and NFS Setup 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 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 assumes you have two IB hosts named host1 and host2): host1> ifconfig ib0 a.b.c.x host2> ifconfig ib0 a.b.c.y host1> ping a.b.c.y host2> ping a.b.c.x host1$ ifconfig ib0 a.b.c.x host2$ ifconfig ib0 a.b.c.y host1$ ping a.b.c.y host2$ ping a.b.c.x 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.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 cleint's iWARP address(es) for an RNIC. The IP address(es) is(are) the client's IPoIB address for an InfiniBand 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 use a reserved port. NOTE: The "insecure" option must be used because the NFS/RDMA client does not use a reserved port. Each time a machine boots: Loading @@ -214,43 +227,45 @@ NFS/RDMA Setup For InfiniBand using a Mellanox adapter: > modprobe ib_mthca > modprobe ib_ipoib > ifconfig ib0 a.b.c.d $ modprobe ib_mthca $ modprobe ib_ipoib $ ifconfig ib0 a.b.c.d NOTE: use unique addresses for the client and server - Start the NFS server If the NFS/RDMA server was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in kernel config), load the RDMA transport module: If the NFS/RDMA server was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in 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 > service nfs start $ service nfs start 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 If the NFS/RDMA client was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in kernel config), load the RDMA client module: If the NFS/RDMA client was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in 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 "proto" field for the given mount. To verify that the mount is using RDMA, run "cat /proc/mounts" and check the "proto" field for the given mount. Congratulations! You're using NFS/RDMA!
Documentation/networking/bonding.txt +80 −30 Original line number Diff line number Diff line Loading @@ -289,35 +289,73 @@ downdelay fail_over_mac Specifies whether active-backup mode should set all slaves to the same MAC address (the traditional behavior), or, when enabled, change the bond's MAC address when changing the active interface (i.e., fail over the MAC address itself). Fail over MAC is useful for devices that cannot ever alter their MAC address, or for devices that refuse incoming broadcasts with their own source MAC (which interferes with the ARP monitor). The down side of fail over MAC is that every device on the network must be updated via gratuitous ARP, 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 fail over MAC 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. A value of 0 disables fail over MAC, and is the default. A value of 1 enables fail over MAC. This option is enabled automatically if the first slave added cannot change its MAC address. 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 same MAC address at enslavement (the traditional behavior), or, when enabled, perform special handling of the bond's MAC address in accordance with the selected policy. Possible values are: none or 0 This setting disables fail_over_mac, and causes bonding to set all slaves of an active-backup bond to the same MAC address at enslavement time. This is the default. active or 1 The "active" fail_over_mac policy indicates that the MAC address of the bond should always be the MAC address of the currently active slave. The MAC address of the slaves is not changed; instead, the MAC address of the bond changes during a failover. This policy is useful for devices that cannot ever alter their MAC address, or for devices that refuse incoming broadcasts with their own source MAC (which interferes with the ARP monitor). The down side of this policy is that every device on the network must be updated via gratuitous ARP, 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 Loading @@ -338,7 +376,8 @@ max_bonds Specifies the number of bonding devices to create for this instance of the bonding driver. E.g., if max_bonds is 3, and 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 Loading Loading @@ -501,6 +540,17 @@ mode swapped with the new curr_active_slave that was 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 A string (eth0, eth2, etc) specifying which slave is the Loading
