[ Site Index] [ Linux Index] [ Feedback ]
Fun with filesystems
It probably won't come as a surprise to you if I mention that I own both a laptop and a desktop PC -- and they both run Linux. I'm not going to bother justifying this flagrant abuse of resources; they're mine, dammit, and I use them for different tasks. (Yes, writing a Linux column down the pub is a different task from writing it in the office. That's my story and I'm sticking to it!)
However, some interesting problems arise if you want to use two machines as your main workstation: the largest of which is my home directory -- which runs to about 1.6 gigabytes in size. How did it ever get that big? (I remember when a 10Mb hard disk drive that whined like a truck turbocharger and was slow to start on a cold morning felt enormous.) Well, when you combine the past few years' magazine columns with the past decade's email folders, it tends to take up a little bit of space. When you add various other work and software projects, things bloat up further. Add the efflux of a digital camera and space will presently be getting a little tight.
There are a couple of solutions to the problem of having bags of personal files and working on two or more machines. Solution number one is to ignore the problem and hope it'll go away; I confidently predict that if you try it you'll give up on this one the first time you discover that an important business letter you need to quote is on the other machine. A second solution is to designate the desktop box as a backup server, and spool everything onto tape; this works insofar as you won't lose any data, but it doesn't help organise things. A third solution, favoured by corporations, is to distinguish workstations from fileservers. All personal files reside on a big file server which makes them available via NFS (or SMB, or AppleTalk) to the client machines. This works very well ... except for laptops working away from home, or until your file server crashes for some reason.
So what's the answer?
One answer to keeping your files synchronised is to keep mirror images of the common directory tree on each machine, and synchronise them using some mechanism like rdist or ftp. (Rdist is a program to maintain identical copies of files over multiple hosts. Ftp, the file transfer protocol, is exploited by a number of tools -- such as mirror -- to keep directory trees up to date.) This is okay as far as it goes, but it requires tiresome manual intervention. Probably a better solution to synchronisation is to leave it to the filesystem. Just tell both your machines that your home directory lives on a special distributed filesystem, and leave the logic of sorting out changes to the filesystem itself. Which is where Intermezzo comes in.
In the beginning, researchers at Carnegie Melon University in the States were working on something called the Andrew Filesystem (AFS for short). AFS was a research project that aimed at inventing a filesystem that was fault tolerant. A whole bunch of networked servers would each set aside a chunk of disk space as belonging to an AFS volume. In turn, a bunch of client workstations would be informed of the machines in the AFS server cluster and would mount the volume as a remote filesystem. Any file plonked into a mounted AFS volume by a client would be written not onto a single server's disk, but onto all the servers. And if one of the servers crashed or was disconnected from the network, the others would take over, answering file requests.
But there was more to AFS than this. AFS was commercialised by IBM (and has now come full-circle with the release under an open source license of OpenAFS for Linux); meanwhile research continued on Coda. Coda added client-side cacheing. If a client workstation is disconnected from the cluster of Coda servers due to a network failure, it can still see local cached copies of the files it was working on; the client's users can edit these files, and when the workstation reconnects to the network it will send the updates to the Coda server cluster (where they will be integrated with the primary copy on the shared volume).
Coda basically provides for a permanently on-line fault tolerant file service -- one that a laptop user can plug into, then unplug from, and continue using even when disconnected. But Coda is big, wobbly, and rather experimental. Using it on my simple desktop/laptop configuration is massive overkill. Which leads me to InterMezzo.
InterMezzo is a new, lightweight distributed filesystem that is currently in beta test. Developed on Linux, InterMezzo consists of two components; the Presto kernel module (which is a wrapper around a local disk filesystem), and the Lento userspace cache manager and file server. When you mount a filesystem as type "InterMezzo", you're mounting a standard ext2 filesystem -- through the Presto wrapper. Presto intercepts access to files and directories to check for currency of the data, and captures updates to the filesystem and adds these to an update journal. In turn, the Lento cache manager asynchronously transmits the journaled updates back to the primary server (whenever it's accessible), and requests cache "misses" from the file server whenever necessary.
The way it works with a laptop/desktop combo is fairly straightforward. You ensure that your /home directory is mounted on a different filesystem from your root system (this is a good policy in any event; it makes backups and system upgrades easier). Install the InterMezzo software on both the client and server machine, and follow the instructions in the HOWTO for setting up a single server and single client. (Essentially these require you to create a directory /etc/intermezzo, and write some small configuration files in it: sysid (which identifies the current system by name), serverdb (a database of servers), and voldb (a database of sharable volumes). Having written these files, you then edit /etc/fstab so that instead of /home being mounted as a straightforward ext2 filesystem, it is mounted as an InterMezzo filesystem (with various options described in the HOWTO). Mount the /home filesystem as usual on each system, then on each machine start the lento server. Whenever you write a file into /home on your client, it will shortly thereafter appear on the server, and vice versa. More importantly, if you disconnect the machines, the client will still be able to see the contents of /home and read or write the files there; when reconnected the changes will be propagated to the server.
Now for the bad news. InterMezzo is still in development and it probably isn't a good idea to trust your critical data to it yet. For example, there's no security subsystem; if someone else can stick their laptop on your network while you're absent and configure it as an InterMezzo client they can grab your home directory and data. Nor is there security at the network layer; your files will be transmitted without encryption. The security issues are due to be fixed by integrating SSL for authentication (host to host and user to host). Additionally, InterMezzo is going to be integrated on top of either ReiserFS or ext3, the next-generation journaling filesystems that will replace ext2 in the near future -- thus adding to InterMezzo's ability to withstand crashes -- and one implicit goal is to be able to handle file locking (to help keep mail directories in sync).
Plug and go
Keeping my home directories in synch isn't the only problem with running a laptop and a desktop machine. Dialup networking while I'm on the road isn't hard; the desktop box is permanently connected via a cable modem, and I have a modem configured to use Demon Internet on the laptop. In fact, I can log into my desktop box via ssh while I'm on the road.
(A minor digression. I use Telewest's cable modem service. Telewest have some very odd ideas about how to manage a DHCP server. DHCP, the dynamic host configuration protocol, is used by ISPs to assign temporary IP addresses to dialup clients, so that instead of having to assign a different IP address to each customer, they can use a smaller pool of addresses -- this is one response to the IP address depletion problem. Just why they feel it is necessary to force cable modem users -- who are connected 24 hours a day -- to use dynamic IP addresses is a mystery; nevertheless Telewest allocate IP addresses and hostnames via DHCP. At least, that's what they say they do: in practice, the IP address on my cable modem only changes when they upgrade their core routers, although the hostname seems to be a random variable. Oh, and they don't seem to be able to run a distributed DHCP service either, as witness the 96 hours of outage I had in one memorable week in September. But this digression has gone on for long enough, and ADSL isn't available in my area yet, so ...)
The situation I face is that I have a home system (with a fixed IP address) and a mobile system. I can connect via a local ISP, talk to my home system, then disconnect again. But is there any means by which I can keep a connection running while I roam?
One technology that I don't use -- yet -- is Mobile-IP. Mobile IP is designed, according to the IETF, "to permit IP nodes (hosts and routers) to seamlessly "roam" among IP subnetworks and media types. The Mobile IP method supports transparency above the IP layer, including the maintenance of active TCP connections and UDP port bindings." (Translation: your laptop can switch networks, but you'll stay connected to your base station as if nothing has changed.)
The way it works is that your laptop or mobile appliance has two IP addresses instead of one. One of these addresses is the home address of your laptop -- this is fixed and permanent. The other is a "care-of" address, and is assigned by whatever network it happens to be plugged into. There's some smart software running on your router back home, and whenever your laptop is plugged into a new network it sends a packet to your home router saying, basically, "hi, it's me
again, please forward all my packets care of ". The router at your home site is advertising your permanent address; whenever a packet for your laptop's permanent address arrives it forwards it via a tunnel to the care-of address, where your laptop picks it u. Thus, your laptop appears to be continuously connected via a single IP address, even when it's moving around.
The IETF go on to say, "where this level of transparency is not required, solutions such as DHCP and dynamic DNS updates may be adequate and techniques such as Mobile IP not needed." Whew. That's where I am today -- so why might I be interested in Mobile-IP?
Mobile-IP does for internet connectivity what the cellular telephone system does for telephony. When you pick up a fixed-line telephone, the switch at the exchange establishes a connection between your handset and the telephone you're dialing the address of. Want to move to another building? You've got to put the phone down and dial in again. In contrast, when you're on a cellular network your phone is in intermittent radio contact with the base station (which is wired into the phone network). Whenever you move between radio cells, your phone basically tells the local base station, "hi, it's me, please forward any calls for me to this cell." And, due to a miracle of distributed computing, your phone calls end up going to your handset.
Mobile-IP is pretty experimental at this stage; it's really only useful in big companies where everybody uses laptops and a wireless network cards to stay connected to the network continuously while moving around. But if we're ever going to see internet connectivity become as ubiquitous and mobile as telephony has become, something like Mobile-IP is essential. Imagine in a couple of years' time you've got that wireless ethernet card in your laptop. As you move around town, you don't bother with a modem. Instead, whenever you get within fifty metres or so of a building with a fixed leased line, your network card makes contact with the owner's router: it negotiates a Mobile-IP care-of address on their LAN, migrates your (encrypted, secure) tunnel to your home server over, and (where appropriate) arranges to pay for the bandwidth automatically.
This vision may not arrive, but if it does it will make an end run around one of the current limitations of laptops -- the low bandwidth they're forced to put up with from the phone system. A situation that isn't going to be cured by GPRS (general packet radio service, a next-generation cellular data service with a maximum theoretical speed of 160kbps), even though it's an improvement over trying to read your mail at 9600 baud using a current generation GSM phone.
In case you were wondering, a Mobile-IP implementation for Linux is already available, albeit not yet ready for prime time, from Helsinki University in Finland, the most cellphone-wired country on the planet: you can find their source code here. You won't find it routinely integrated into Linux distributions for a while because it's still under development (although if you want to experiment with it packages for Redhat and Debian based distributions are available), but its existence is significant because of the appearance of Linux in the embedded systems market. If you can build Linux into a tablet-sized device with a screen, pen input, and a web browser based on Mozilla, then add Mobile-IP and a GPRS transceiver to it, you have a royalty-free gadget that lets you browse the web at ISDN speeds wherever you happen to be. Which is a marketing opportunity that several companies, among them graphics card manufacturer S3, are paying attention to.
Kernel 2.4 arrives
It's overdue by the best part of a year, but the new release 2.4 of the Linux kernel should be finalised around the time this magazine goes to press (in December 2000). We're already seeing pre-release candidates, and the official 2.4 release is down to last-minute bugfixes.
Linux version numbering doesn't follow the fashions of marketing: it follows the whim of Linux. In the beginning, there was a release 0.1, rapidly followed by 0.11 then 0.12, then (confusingly) 0.9. Finally, when the kernel matured, Linus declared one version to be 1.0 -- this was back around 1994.
Thereafter, Linux was switched to an odd/even version numbering system. Odd-numbered versions, such as 1.1 or 1.3, are development releases; even- numbered versions, such as 1.2 or 2.4, are production releases. Each release number is followed by a minor number (such as 1.3.54 or 2.2.23) that indicates a patch level. This dual numbering scheme is necessary because even after a stable production release (like 2.0.0 or 2.2.0) is made, bugs come to light and need fixing; the current release of the 2.2 series, for example, is 2.2.17, while development of the 2.3 series went into three digits of releases. When the 1.3 development kernel was mature enough, Linux decreed that due to the huge number of changes that had gone into it (compared to the 1.2 production series), it was to be released as version 2.0; arguably, the development kernel after 2.4 is released (2.5?) will give rise to Linux 3.0.
(This is in contrast to Microsoft's weird version numbering. In the beginning there was Microsoft and IBM's OS/2 operating system. After OS/2 1.3, this forked, as IBM and Microsoft went their separate ways; IBM release OS/2 2.0, while Microsoft renamed OS/2 as Windows NT and released their version as Windows NT 3.0 -- rapidly superseded in use by NT 3.51, then NT 4.0, then (for no rational reason) Windows 2000. At least it's possible to tell from the version number of a Linux kernel which other versions it supersedes ...)
Anyway. What's special about Kernel 2.4? (And the 2.4-ready distributions, such as Redhat 7 and SuSE Linux 7.0, that you can drop it right into.)
For starters, the virtual filesystem layer and the disk cache system has been re-written for efficiency: the kernel should now be faster at writing data to multiple disks and can scale up to larger systems. The old limit on processes or threads running under 2.2 has been raised, with up to sixteen thousand concurrent processes reported on some PC-grade systems: but the 2.4 kernel doesn't actually use any more memory for its internal processes. (However it can come with more memory, up to 4Gb on Intel architecture machines -- kernel 2.2 maxed out at 1Gb without a special patch.)
There are a variety of filesystem changes. 2.4 will support NFS v3, the current latest release of Sun's Network File System. ReiserFS hasn't made it into the final release, but it is expected that the ext3 journaling filesystem will show up in 2.4 subsequent to the initial release (and so, possibly, will SGI's XFS filesystem). Below the filesystem level, kernel 2.4 has improved support for large numbers of IDE controllers and better control of UDMA chipsets (used on fast IDE drives). There's also raw device i/o support -- useful for providing big relational databases (such as Oracle) with direct access to a chunk of disk space without going through a filesystem.
There's greatly expanded support for USB and FireWire devices in the 2.4 release, including some support for scanners, printers, hard disks, and cameras over USB. ISA Plug'n'play support finally works the way it ought to (just as ISA PnP is going out of date!), and PCMCIA support for laptops is now a standard part of the kernel rather than a separate configurable item.
The Video4Linux subsystem has received a bit of an overhaul; kernel 2.4 has additional drivers for a variety of video and audio cards, and also now includes support for a speech synthesizer card (with braile terminal support being added separately by SuSE).
Probably the most significant change (but hardest to evaluate) is the complete re-write of the networking subsystem. Kernel 2.4 now has a more complete and scaleable TCP/IP implementation, and already some tools are showing up that take advantage of this (such as an in-kernel web server designed to serve static HTML pages and images as fast as possible, with blistering benchmark results). (There's also a new IP filtering system to replace IPchains and IPfwadm in the construction of firewalls.)
And as a final note -- kernel 2.4 runs on more architectures than ever before, including IBM Series 390 mainframes, ARM machines, Sparc64 and Intel's IA64 architecture. In fact, Linux is now the most widely ported operating system in the field.
Is there any reason not to upgrade to kernel 2.4?
Unlike commercial operating systems, kernel 2.2 will be around and supported for a long time. It's stable, and if you have a production machine running on it you really shouldn't risk destabilizing it. On the other hand, if you need USB support, kernel 2.4 will be a distinct improvement; and the lessons of 2.2's premature release seem to have been taken on board and applied particularly thoroughly to ensure that there won't be any show-stopping bugs in early 2.4 kernels. Certainly if you're running a recent distribution that's kernel 2.4 ready (such as Redhat 7 or Caldera Technology Preview) it would be fun to download the new kernel and experiment with it!
[ Site Index] [ Linux Index] [ Feedback ]