Pages

03 March 2008

Nautilus in Hardy uses GVFS (aka gio) instead of GnomeVFS. A feature we should be seeing from this soon is the ability to restore from trash. Right now, though, I just think it's cool that when transferring data from my roommate's laptop to mine (I borrowed hers while mine was being repaired) over a USB connection, I saw this:

Yep, it's showing the USB transfer speed. And wow, it's beating the crap out of my flash drive. My flash drive has been doing 1MB every two or three minutes, so it's pretty much dead. Nautilus is being a bit of a CPU hog about it, though. It's using about 30% of my CPU, according to top. I don't usually use Nautilus, but I heard this was going to be a new feature, so I wanted to see if it was implemented yet. Besides, the cp command doesn't show nice little [=======> ] progress bars like wget does.

For the transfer, I'm using a MacAlly (yes, the company that makes after-market accessories for Macs) PHR-250A slim 2.5" USB-powered enclosure. It's extremely thin. If I wasn't a girl, it'd fit in my pocket (girl pockets are made really small so they can force purses on us, I swear). The only downside is that it takes up 2 USB ports: 1 for transfer, 1 for power. It claims it can get up to 480Mb/s. We'll see about that.... That's the max speed the USB 2.0 standard can handle, but I don't think it's really guaranteed that anyone's USB controller on their laptop/desktop can handle that, so they could always blame slower speeds on that.

Also, just so that it's known, USB is a very CPU-dependent protocol, so likely a great deal of that CPU overhead is coming from the CPU. Nautilus doesn't do a whole lot while it's copying besides updating that dialog (which isn't expensive at all), it's mostly out of context work; either GIO does the heavy lifting in the case of local files, or GVFS during remote file reads and writes, and those systems defer much of their work to the UNIX/backend-specific (libsmbclient/libsoup/etc) libraries.

If the CPU usage is still high while doing on-system copies, that's something we can target and attempt to fix, but I suspect a large part of that is just USB overhead. *insert Firewire-is-superior rant*.

One last note: as a part of GVFS, we have nifty new command line utilities that do show progress: gvfs-copy -p will show you the progress of the file it's copying (in a rather spammy way, but it works). If that's still taking lots of CPU time, it's at least not a Nautilus issue.

Top was actually showing Nautilus and USB*something* (usb-transfer, maybe) as separate processes. I had it sorted by CPU usage, and the usb-transfer was 2 steps below Nautilus, still in double-digits, I believe.