Cisco Goes Wide for File Services

Cisco Systems trotted out a network appliance that quickly simplifies the management and storage of files located in branch offices.

Using software it owns from its August purchase of Actona Technologies, Cisco has created the File Engine Series to provide its own brand of wide area file services (WAFS).

Cisco's wide area file services allows companies to consolidate storage and server infrastructure, such as file and print servers or tape back-up devices, from the branch or the edge into the data center, said John Henze, director of marketing for Cisco's caching services business unit.

The challenges of managing data growth in a distributed environment are well documented, Henze said, quoting an IDC report that found that as much as 60 percent of a company's data sits outside its data center and resides at the edges on file servers, desktops or laptops.

"Trying to do that in a distributed environment where you have dozens or hundreds of offices with little to no IT resources on those branch offices becomes a very complex and costly problem for companies," Henze told internetnews.com.

To solve these issues, the File Engine stores master copies of files where they can be protected and managed with the other gear in the data center. By using one device, Henze said customers who use the File Engine can shore up their network defense, as well as ease some of the data transmission pain caused by latency.

The File Engine includes an Edge File Engine, which is deployed at each branch office, replacing file and print servers and giving desktops and laptops fast file access. The Core File Engine is deployed at the data center and connects to one or more file servers or network attached storage (NAS) gateways, processing file requests on behalf of each Edge File Engine.

Cisco is selling its File Engine now with a list price of $12,000, including a license to support up to 50 branch office users. License packs for an additional 50 users cost $4,500.

An emerging technology niche, WAFS overcomes performance issues associated with standard file access protocols, such as Common Internet File System (CIFS) (define) for Microsoft Windows environments and Network Files System (NFS) (define) for Unix environments.

Until the technology appeared in the last couple of years or so, there was no quality way to solve the latency issues involved in accessing files over long distances. That is quickly changing: Companies such as Cisco and standalone rival Tacit Networks extol the virtues of WAFS, and each intends to corner the nascent market.

Linux Runs on Text: Understanding & Handling Text

Text plays a central role in the Linux operating system. Take better control of your system with a firm understanding of what text is and how best to handle, format and convert it.

This month, as another part of the series about using text on Linux systems, we’ll introduce “plain text” and how you can restructure it. We’ll see how to identify text from different systems (Unix, DOS, Mac) and to convert text between systems. The article ends with some examples, and there’ll be lots more next month.

If you’re used to clicking on files to view and edit them, you’ll probably find some new tools and concepts here. Gurus, please have a look at the main example and be sure it’s familiar.

The fundamental concept is the role of the newline (line feed) character. Reformatting text is basically a matter of juggling newlines. Let’s dig in.

What’s Text?

As I wrote in last month’s column, Linux runs on text. Text comes in a lot of flavors. What we’ll cover this month is plain text: a stream of characters that you can output directly to a terminal window using a utility like cat(1). The text doesn’t have special formatting codes like “start boldface” or “24 pixels high” that are only understood by certain operating systems or applications. Plain text doesn’t require a word processing program like OpenOffice.org Writer to interpret instructions buried before and between the actual text.

Let’s make a test text file. We’ll use it to demonstrate a lot of things about text. Although the example is a bit tedious, the techniques will be useful, later, when you need to know what’s in a text file. We’ll make this text file on a Windows system, and make a similar file later under Linux.

On Microsoft Windows systems, each line of a plain text file ends with a carriage return (CR) character followed by a newline (LF, line feed) character. Let’s use a “Command prompt” window to copy text typed from the keyboard (con:) into a Windows-format file named win.txt. On DOS-type systems, pressing CTRL-Z followed by the ENTER key ends input. The boldfaced text is user input; the rest is system output:

1. The first command, cat win.txt, shows a file that looks like the text we entered in the DOS window. However, the bash shell prompt, /d/tmp$, comes just after the text line 2 from the file — instead of on a new line by itself.

   Why? It’s because (as we’ll see below) the contents of win.txt don’t end with a newline character. The shell always prints a prompt immediately after the output of a command (in this case, the cat utility) finishes. There’s no newline at the end of the file, so the shell prompt appears on the same line.

2. The second command shows a lot more:
   1. The option -t tells cat to show TAB characters as ^I, so you can see that the indentation before line 1 is caused by a TAB.
   2. The option -v tells cat to show “nonprinting” characters visibly, which lets us see that there’s a carriage return character, shown as ^M, after a space character, following the text line 1.

      Each line of a DOS text file ends with two characters: a carriage return and a newline (line feed). After showing the carriage return visibly, cat output the newline preceded by a $ character:

   3. The option -e tells cat to mark the end of a line with $. This lets you see just where a newline falls.
3. The third command, od -c, shows the character representation of bytes one-by-one. The -w6 option lists six bytes per line. Each line starts with the octal offset from the start of the file. You can see:
   1. The first six bytes (at offsets 0000000 through 0000005) are a TAB character (which od shows as \t), the word line and a space character.
   2. The second six bytes (from offset 0000006) are the digit 1, a space character, a carriage return character (which od shows as \r), a newline character (which od shows as \n), and the first two characters of the next line of the file, li.

      od shows the structure of a text file. The newline character — the end of the first “line” in the file — is just a character. The bytes of the next “line” start immediately after the newline. (As we’ll see later, you can insert newline characters anywhere you want to start new lines.)

   3. The last four bytes (octal offsets 0000014 through 0000017) are the letters n, e, a space, and the digit 2. There’s no carriage return, no newline. That’s because, while making the file, we typed the DOS end-of-input character CTRL-Z before pressing RETURN (ENTER) to end the line.
4. The wc utility reports 1 line, 4 words, and 16 characters.
   1. Because there’s only one newline character, there’s only one “line”. (The second line isn’t complete.)
   2. There are four words: line, 1, line, and 2.
   3. The 16 characters include the carriage return and the newline. (You can see them in the od output, and see the the final offset — 0000020 octal, which shows the number of bytes read — is 16 decimal.) Although the TAB makes a lot of whitespace (it moves the cursor to the next “tab stop” on the terminal, as we’ll see below), it’s only a single character.

Server Evolution

Servers have evolved from decentralized satellites located throughout an organization to more centralized administration hubs. The traditional method for consolidating servers was to stack them in bulky towers. In recent years, however, thinner servers have transformed those towers into slimmer racks. The setup saves space and provides easier access for administrators, but each server typically requires its own power access, network and switching. And the configuration can be a cabling nightmare. According to industry experts, the use of blade servers, which can eliminate many of those obstacles, is the next stage of server consolidation.

The lingo of blade computing is somewhat ambiguous. A blade server is usually considered the chassis or rack - which is designed to optimize the computing process - that in turn stores a number of server blades, which are hot-swappable devices. Each server blade is essentially an independent server that has one or more processors and its own memory and network controllers. Server blades have their own operating system and run their own applications. Individual server blades slide into the chassis - comprising a blade server - and then share a common infrastructure with other blades. Shared components could include a power supply, fans and cooling systems, Ethernet connections, and switching.

Simply, blade technology allows IT managers to pack more computing power into less space. For example, the Egenera BladeFrame System can hold 96 high-end Intel processors in a 24-inch by 30-inch by 84-inch chassis. IBM's BladeCenter T chassis allows firms to pack 80 processors in an 84-inch rack. Traditional server racks typically hold no more than 42 devices.

Tim Dougherty, IBM's director of blade strategy in Armonk, N.Y., says blades "enable you to simplify your data center." By combining things like servers, switching and Ethernet inside "the same enclosure, you not only get savings in power and space," but it makes it easier to manage the entire system, he asserts. "It's a much easier infrastructure to deploy than the rack-mount servers." And it's cheaper.

According to "Why Blade Servers?" by Mark Chapman of the IBM Server Group, blade servers have six major cost-savings advantages over traditional rack servers:

- Lower purchase price. Blades eliminate the need for duplicate components and can reduce cabling costs.

- Lower installation costs. Traditional rack servers require assembly, configuration and cabling, much of which is eliminated with blades.

- Less power consumption. By using low-end processors, blades can save money on power and cooling costs.

- Space reduction. The increased density of blade computing allows firms to use less space for more equipment.

- Lower failure costs. Traditional servers require dedicated fans, cables and accessories, increasing the risk of failure. Blades require fewer components, reducing the likelihood of a component failing.

- Scaled purchasing power. Firms can buy just the computing power they need now and add blades as their processing requirements increase in the future.

Despite these advantages, Dougherty notes, winning over Wall Street is no easy task. "Not everybody is convinced they see the value of blades. Some people are a little skeptical of taking things and embedding them in the blade center." But once they see the benefits, he says, "They see value."

Open-Source Creative X-Fi Support

Last Friday 4Front Technologies had released the binaries and source-code to OSS 4.0 Build 1013. This new build of the Open Sound System brings two major changes, which include the full source code now being available for the M-Audio Revolution and Delta sound card drivers, and a beta driver for the Sound Blast X-Fi series from Creative Labs. While earlier Sound Blaster generations have worked quite well with ALSA and OSS, the Creative X-Fi series is a black sheep under Linux. The X-Fi support that Creative Labs has provided to the Linux community has been abominable and support via ALSA (the Advanced Linux Sound Architecture) has yet to go anywhere while support for the complete X-Fi series via OSS is just starting to emerge. Interestingly though, Creative had provided the register documentation and other code to 4Front Technologies for this new "sbxfi" driver.

In June of 2006, Creative Labs had pledged an X-Fi Linux driver with full support for ALSA and OpenAL v1.1 with EAX (Environmental Audio Extensions) to be delivered in Q2'2007. The X-Fi series was introduced in August of 2005 and nearly two years later Creative had planned to deliver a binary-only Linux driver. However, come second quarter of 2007 it was announced that this driver wouldn't even reach beta until late Q3 or early Q4 because of Creative devoting more resources to Microsoft Windows Vista (Vista Makes Creative Labs Dupe Linux). Finally in late September was the first beta release, but another caveat to this closed-source support is that this driver only supports x86_64 Linux with no option for 32-bit users (X-Fi Driver Only Supports 64-bit Linux).

Since that September x86_64 beta driver release, there has yet to be any further updates or Linux software releases from Creative Labs. Creative Labs does maintain a Linux driver issues database (Creative Labs Connect) and that has just filled up with complaints over the lack of 32-bit support, not compiling against Ubuntu, incompatible with GCC 4.0, and other installation issues. In total there are over 100 issues listed with their X-Fi Linux driver.

According to the ALSA Project Wiki, developers do have these cards but as it's a new APU architecture and Creative isn't releasing any datasheets, the only option for them is reverse engineering. However, due to time constraints, there is no active reverse engineering going on right now with the Sound Blaster X-Fi by ALSA developers. Right now development efforts are gearing up for ALSA 1.0.16, but support for these newest Creative APUs doesn't appear to be a priority for them. This all though could change though thanks to this X-Fi OSS support and what we're about to share.

For the Open Sound System, OSS 4 has supported the X-Fi Xtreme Audio, but no other X-Fi ASICs. This support was there since the X-Fi Xtreme Audio isn't a true X-Fi component. Last week's release of OSS 4.0 Build 1013 is the first to provide playback support for these high-end sound cards. This initial support is considered beta and limited to playback support. There is no hardware mixing support and recording capabilities are considered problematic. The source code though has been published by 4Front Technologies, which last year began open-sourcing the Open Sound System under the CDDL for Solaris and GPLv2 for Linux (announcement) and then last month made OSS available under the BSD license for FreeBSD and other *BSD operating systems. The X-Fi generations currently supported by the OSS "sbxfi" driver include the X-Fi SB046x/067x/076x, SB073x, SB055x, and UAA "Vista Compatible" sound adapters.

This OSS X-Fi driver, however, wasn't reverse engineered. The main driver file (sbxfi.c) combined with its accompanied header file is just under 1,000 lines long and is licensed under the GPLv2 (or CDDL, BSD depending which copy is downloaded). This driver though includes hwaccess.c, hwaccess.h, and 20k1reg.h. These files are copyrighted by Creative Technology with markings of "Confidential & Proprietary", "Private & Confidential", and "Creative Confidential" with no open-source license being mentioned. This Creative code contains the registers for the X-Fi series as well as functions for initializing and accessing the X-Fi 20k1 hardware. In total, this Creative Labs code makes up about 2,400 lines.

We have tested OSS 4.0 Build 1013 with an X-Fi XtremeGamer and were greeted with positive results: the audio playback had actually worked. While this driver from 4Front Technologies is considered beta, this driver is in a much better state than what Creative Labs considers beta for their binary x86_64-only Linux driver. Will Creative just abandon their X-Fi binary driver? It's going on five months since their driver was last updated. This register information and hwaccess code should certainly be able to jumpstart the ALSA efforts with developing an X-Fi driver. Once there is a Sound Blaster X-Fi driver for ALSA, we can then finally see "out of the box" support for these high-end sound cards in most Linux distributions, but it's coming three years after the hardware first shipped. We have contacted Creative Labs and are awaiting comment on their Linux plans. If you are looking for a high-end sound card for immediate use, the Razer Barracuda AC-1 and other sound cards based upon the C-Media Oxygen HD CMI8788 APU have evolving open-source support through the snd-oxygen ALSA driver.

Creative Tries Again At Linux Drivers

Next to drivers for graphics cards and (Atheros and Broadcom) wireless chipsets, the Creative Labs X-Fi series is one of the most complained about pieces of hardware for its Linux support or there the lack of. The Creative X-Fi sound card series is a few years old, but it wasn't until a few months ago that open and closed-source drivers started coming about for this hardware. However, this sound card has still been left in a sorry state, but this week Creative Labs has finally pushed out another Sound Blaster X-Fi Linux beta driver. But does this driver correct their wrong doings from the past?

Since the first half of 2006, Creative Labs has been stating their intention of providing an X-Fi driver that supports Linux with full capabilities for ALSA and OpenAL 1.1 with EAX (Environmental Audio Extensions). Their plans were to provide this closed-source driver in the second quarter of 2007, but then come Q2'07 they had duped Linux for Microsoft Vista. It had taken Creative Labs more resources to develop a Vista-capable driver than they had anticipated and as a result, their Linux driver development suffered with their release schedule being pushed back by several months.

Finally in September we found out that an X-Fi Linux driver was coming soon but as a beta release. On September 24, 2007 that driver was finally delivered but it in a horrific state. This closed-source X-Fi beta driver had only supported x86_64 Linux (read: no support for all of the 32-bit Linux users) and hadn't even worked with GCC 4.x. In addition, the driver had its share of other bugs.

Months went by after that release with no signs of another beta, but back in February of this year, 4Front Technologies had announced an update to the Open Sound System (OSS) with initial support for the X-Fi series. Unlike support for some of the other sound cards on the market, the X-Fi support in its (sbxfi) driver wasn't reverse-engineered but Creative Labs had provided some source-code and header files to 4Front Technologies (Open-Source Creative X-Fi Support). These code files though had confidential markings, but two days later it was found out that this was legal and Creative Labs is interacting with both the OSS and ALSA projects. They had finally joined the open-source bandwagon.

After seeing this Open Sound System support and anticipating Sound Blaster X-Fi support for the forthcoming ALSA 1.0.17 release, we thought the Creative closed-source driver might just be dead. However, this week a second unsupported beta driver has finally been released. This driver supports the Creative Sound Blaster X-Fi XtremeMusic, XtremeGamer, Fatal1ty, Platinum, and Elite Pro models. It supports ALSA mixing, recording, and PCM playback, while the new features in this beta release is support for GCC version 4 and Linux 32-bit distributions. Major issues still not addressed are S/PDIF pass-through support and compatibility with external I/O modules.

The Linux "XFiDrv" is at version 1.18 for this beta release. We are in the process of testing out this driver and we will report back if there's anything interesting to hear. There is no report yet what other bugs this beta driver might have addressed. Now that there is GCC 4.x and 32-bit support, this may be a good temporary driver until the open-source X-Fi support matures. For X-Fi sound card owners, this driver can be downloaded from the Creative Open-Source Wiki.

NVIDIA 100.14.09 Display Driver

We have previously looked at the NVIDIA 100.14.03 and 100.14.06 display drivers, but this afternoon we finally have our hands on the stable NVIDIA 100.14.09 driver. New in version 100.14.09 is added GeForce 8 and Quadro product support, improved notebook GPU support, improved RenderAccel support for sub-pixel anti-aliased fonts, added Xv brightness and contrast controls, improved interaction with newer kernels, and fixing an issue with nvidia-settings. The new yet-to-be-released GeForce 8 names have also tipped up in the release notes. We've seen many of these features introduced in the previous 100.14.xx builds, but they are now officially supported.

The new product support in the NVIDIA 100.14.09 driver is for the GeForce 8300GS, 8400M G, 8400M GS, 8400M GT, 8400GS, 8500GT, 8600M GS, 8600M GT, 8600GT, and the 8600GTS. We've seen the GeForce 8500 and 8600 products in the NVIDIA 100.14.06 release (see our NVIDIA GeForce 8500GT review), while their new mobile "M" parts have yet to be officially announced. Among the new Quadro cards with official Linux support is the FX 1600M, FX 570M, FX 360M, NVS 320M, NVS 140M, NVS 135M, and NVS 130M. This driver also supports the Quadro FX 5600 G-Sync and the Quadro FX 5600 G-Sync products. In the NVIDIA 100.14.06 review we shared with you that the notebook improvements include no longer needing mobile kernel options for the NVIDIA driver and other bug fixes.

The 100.14.09 driver also contains improved RenderAccel support for sub-pixel anti-aliased fonts along with adding Xv brightness and contrast controls for GeForce 8 graphics processors. The next change is improved interaction with newer Linux kernels, which should officially work now on the Linux 2.6.21 kernel and the 2.6.22 release candidates thus far. Last but not least, this driver fixed a locale-interaction issue with the nvidia-settings configuration file parser. This driver does not fix the black window bug issue that some Beryl/Compiz users experience (still a few more months until it will likely be resolved).

Introducing The RadeonHD Linux Driver

Not only is AMD providing the open-source community with their ATI GPU specifications, but they have also been partnering with Novell on the development of a new open-source display driver. We've been telling you about AMD's open-source work all month, and today the new driver is finally available for download. It is still very much a work in progress and isn't much further along than the open-source R500 Avivo driver. However, this new driver does support the Radeon HD 2000 (R600) family. This new X.Org driver is called RadeonHD and in this article we have some initial information to share with additional articles coming later in the day.

To no real surprise, the RadeonHD driver is hosted over at FreeDesktop.org and you can checkout the latest code using git. In another article we are publishing today, we will be telling you how to install this new open-source driver on Ubuntu 7.10 Gutsy Gibbon -- that is for those of you who aren't familiar with using git or building drivers from source. If you haven't already, you'll also want to read AMD's Open-Source Strategy Explained.

The RadeonHD driver is largely being written by Novell/SuSE and they have been writing it for the past couple of weeks using the same documentation that was released freely to the open-source community last week. Novell developers will continue contributing to the RadeonHD driver as well. The specifications available to the community so far are just register reference guides for the RV630 and M56, but AMD will be releasing additional documentation (including for 3D functionality) once the documents are sanitized and then cleared by their legal department.

Don't expect any miracles from this driver just yet. At this point, the RadeonHD driver is really targeted for developers and those wanting to use the experimental driver whether it is due to problems using the fglrx driver on the system or just wishing to test out the driver to see if it works for you. As long as AMD sticks to their word on delivering the rest of their documentation, there will not be too much (if any) reverse engineering that needs to take place for the R500 and R600 series. However, the driver is still likely a few months out from a stable point for 2D users (perhaps in time for X.Org 7.4) and then the 3D work after that. Granted, depending upon how many X.Org community members end up contributing and the rate at which AMD pushes out new documentation, the timeline will certainly change. You can see comments by some of the known X.Org video driver developers in this article.