One idiot's blog

The Next Generation of cp

One of the things Hans Reiser, creator of ReiserFS, mentions in this interview is that the cp utility -- one of those utilities you learn probably on your first day of learning any Unix-type system, and one of the most often used -- could be speeded up in a number of ways, including, on Linux, by using the sendfile() system call, which copies directly between file descriptors without the data passing into userspace. Don't ask me what that means; I barely understand it myself. Anyway, I decided to give it a shot, just to see. I coded up the following:

#include <sys/sendfile.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

int main(int argc, char** argv) {
    int in_fd, out_fd;
    int num_bytes;
    off_t offset = 0;
    in_fd = open(argv[1], O_RDONLY);
    out_fd = creat(argv[2], 0666);
    while (num_bytes = sendfile(out_fd, in_fd, &offset, 131072)) {
	if (num_bytes == -1) {
	    printf("sendfile error!\n");
	    return -1;
	}
    }
    printf("Done!!!\n");
    return 0;
}

Well, the above is after I fixed it from some minor compile-time errors: spelled "creat" wrong initially, forgot to include the headers needed for "open", and had some mismatched parentheses in there somewhere.

Then I found a nice big file to copy, and attempted to copy it with this new utility while timing it.

• Observation 1: My quick-and-dirty utility worked perfectly the first time. I rule.¹
• Observation 2: The time for copying with my utility was around 6.5 seconds, vs. around 8.3 seconds for cp. Not a breathtaking improvement, but an improvement nonetheless.

Perhaps the improvement would be greater if the copying were going from one disk to another. But my code looks about as bare as you can get it, so for a copy within a disk, that appears to be about as good as you can get. I started off with the byte count at 65536, but got about the same speed when bumping it up to 2¹⁷. Perhaps an even larger count would be needed before you could see a difference?

I hereby release this code to the public domain, for the betterment of all mankind. I just can't wait to see it pop up in the next version of Fedora as a drop-in replacement for cp.

[1] except that it preserves the permissions of the source file, even though I'd swear that calling creat() with 0666 should give the newlly created file those permissions.

Foregone Conclusion

"The Senate is well along in the process of finding Judge Roberts qualified."

-- G.W. Bush, Sep. 5, 2005

"We're gonna give you a fair trial and then we're gonna hang ya."

--Popular saying about Old West justice.

Back to Sawfish

How many of you GNOME users still miss the Sawfish window manager? The default (and increasingly hard-to-change) Metacity has gotten pretty good over the years, but they evidently made a decision early on that "viewports" are something that is not desired in a window manager, and would never be supported. This sucks.

You can get a good description of the functionality of viewports here. I pretty much agree word-for-word with the opinions expressed on that page. Given that the ability to have an extended desktop seems to be built in to X, to deny the user any way to take advantage of that can certainly fairly be called "broken and feature-poor".

Anyway, having done some cleanup of my Gentoo install and restoration of my "world" list, I discovered that a new version of my old favorite wm, Sawfish, was available for emerging without any conflicts. So I decided to give it another go, even I haven't gotten it to cooperate with GNOME since version 2 came out. Well, the above-linked article got me up and running with viewports in Sawfish under GNOME! Yay.

Unfortunately not much work evidently has been done on Sawfish since it fell into disgrace with the simians at the GNOME project. Not that a lot needed to be done, really; the only thing I felt was missing was a task switcher dialog similar to what Windows has. Metacity does have this; the best Sawfish can do is put up something that looks more like a tooltip, with a single icon for the app that would get the focus if you released the Alt key at that moment. Better than nothing, but you can't see where you've been and where you're going, so it's not all that useful.

The thing that makes Sawfish/viewports indisputably BETTER than Metacity and its ilk is that if you get a GUI which is longer or wider than your screen, you can flip down to the next viewport to see the rest of it or click on the buttons which will likely be at the bottom. Some less capable WMs, like WindowMaker, at least allow you to drag the window indefinitely in any direction, so you can get around that problem. With metacity, if you find yourself with a window that's taller than your screen and not resizable, you CAN'T slide it up to get at the lower parts. A good app writer is forced to take things into account, but there's no guarantee he will, if he's using a nice 1600x1200 screen and/or WindowMaker or something.

I have definitely run into this in the past; KDE's control center used to be bigger than what I was running, which was probably 800x600. I simply couldn't configure KDE, because I couldn't get at the controls and save my settings, so I became a GNOME man. I haven't run into this in such an extreme way in a while, though. I run higher resolutions, for one thing. And the one app I run which opens taller than my screen height -- my CMS tool at work, is compressible. It's a bit of a pain, but essentially I can squeeze down the parts I'm not interested in to make the GUI fit in my window so I can reach the "OK", "Cancel", etc., buttons at the bottom.

Meanwhile, the task switcher dialog is important enough to me that I'll probably keep using Metacity. It's good to know that I have sawfish in my back pocket if I ever need it, however.