Archive for the ‘General’ Category

Using ZFS for replication

Monday, December 3rd, 2007

I have written up how I set up a server with ZFS for remote replication here. When trying to sync hundreds of gigabytes of small files, solutions such as rsync do not cut it. ZFS scales well, its fast, and replication is pretty much free.

Wireless

Sunday, July 29th, 2007

Over the last two months I have been working on the FreeBSD wireless code. Having a single net80211 stack is a huge benefit and the wireless drivers tend to be around 1/4 of some other operating systems. The driver is an interface to the hardware and leaves beacon processing, state changes, encryption, scanning/roaming and so on to net80211.

Sam committed a large set of net80211 changes that brought in revamped scanning, background scanning/roaming and changes needed for 11n. As part of this I worked on the iwi, wi and ndis drivers and there is also a pending update to ipw. Hopefully people are testing their setups, the 7.0 BETA is coming up soon which will give the code even more exposure.

Bridging a vlan trunk

Thursday, June 14th, 2007

I finally got around to adding vlan support to the FreeBSD bridge driver. The vlan tag is now used in the bridge forwarding table so that the same device on two different vlans is treated as separate. The vlan changes in if_ethersubr.c made this easy now that the tag is always available in the mbuf header.

Link Aggregation

Monday, May 21st, 2007

In the weekend I added support for the Marker protocol in lagg(4).

The basic function of it is to verify that the interface queues are empty for all the aggregated interfaces. Frame distribution is supressed and a marker frame places on the queue for each interface, the frame will be sent to the partner device and then returned immediately on the same link. Once each frame is received then we can be sure that no other ethernet frames are queued for that port and when all ports are complete then frame distribution is re-enabled.

All this is needed because frames must be delivered in order for Ethernet, the lagg device can send frames over different ports to utilize all the combined bandwidth by hashing the header (ethernet src/dst, vlan tag, ip header, ipv6 header). The hash selects the transmit port and this ensures for each connection the frames take exactly the same path. If a port is added or removed then the hash output is affected since its modulo the number of ports, the marker protocol ensures that frames for a particular connection are not put on a different interface queue and arrive out of order.

My next job is to add bgscan for iwi(4) and hopefully the card will arrive tomorrow.