"Juan Fco. Giordana" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Tue, 12 Aug 2008 00:28:14 -0300:
> Instead of creating symlinks to /var and /tmp I've opted for doing "bind > mounts" to these directories because I think it's more manageable this > way. Also I'm taking into consideration the same approach for portage > (instead of modifying the variables in /etc/make.conf). Symlinks are the older and more traditional approach, well proven (and generally optimized) over decades of use. While in theory possibly slightly less efficient, in practice, it's generally not going to matter much except for the first access directly off of disk, because after that, it'll all be in-memory cache-access. Any time you go to actual disk, it's many times slower than memory access, so any access to anything uncached will take long enough it doesn't really matter. After that first symlink dereference, that bit is cached anyway. It's sort of like debating whether taking the bus or a taxi to the airport will be faster, when your destination (from the US) is China. A few extra minutes at the local end isn't going to matter much, compared to the hours in flight. Bind-mounts are newer, but should be effectively as stable as any mount, and once mounted, it's handled by the kernel directly. Being newer, they're significantly less commonly used, especially since they're new enough most people will intuitively think symlink and not even consider a bind-mount. They may be (probably are but I don't know for sure) slightly more efficient than symlinks, but again, you're debating the equivalent of the taxi ride to the airport when the flight is hours. OTOH, and this is why I excerpted the bit above, I don't see why you don't want to change the make.conf settings. The processing from the portage perspective should be the same either way, but if you point it at the real (dereferenced) location, you'll effectively shortcut the entire dereferencing process, either way. You can then leave the symlinks/bind- mounts in place if desired, for your own use and for anything that has hardcoded the default location instead of properly looking it up in make.conf, but portage will be using direct path accesses and therefore be as efficient as possible (altho I think that's a taxi/bus debate as well). Now, if you /really/ want to make a difference in portage's speed, consider pointing PORTAGE_TMPDIR at a tmpfs. If you've a decent amount of memory, it'll make a HUGE difference, since all the files it normally creates only temporarily in by default, /var/tmp/portage/* will be created in memory (tmpfs) only. Even with a relatively low amount of memory, say a gig (we're talking amd64 system context here, after all, and a gig has been relatively common since its introduction, not some old 1990s 32-bit x86), where tmpfs may be swapped out in some cases, the shortest lived files should never hit disk (swap in the case of tmpfs) at all. That's a LOT of extreme-latency hard-disk I/O avoided!! If you have some serious memory, 2 gig, 4 gig, higher (I have 8 gig), it's even MORE effective, as only the biggest merges will ever hit disk at all, except of course for the initial PORTDIR/DISTDIR operations and the final qmerge to the live filesystem. But for PORTDIR and DISTDIR, yes, reiserfs is a pretty good choice. In fact, here I'm using reiserfs exclusively, for everything (except what's on tmpfs, of course). But some folks don't trust it for their main system, and certainly, before it got data=ordered journalling by default, it was sometimes a bit less than reliable. I've certainly found it reliable since, but as they say, YMMV. Even if you're one who doesn't believe it reliable enough for your main system, however, using it for stuff like PORTDIR and DISTDIR makes a lot of sense, because that stuff can always be redownloaded from the net anyway, if something goes wrong and the data gets corrupted. But... if you're after performance and have at least a gig of memory, do consider pointing PORTAGE_TMPDIR (or indeed all of /tmp and /var/tmp, as I do, with /var/tmp a symlink to /tmp and PORTAGE_TMPDIR pointed at /tmp directly) at a tmpfs. I expect you'll be very happy with the results, tho you might have to tweak a few things a bit if you find stuff disappearing over reboots that you want to keep. (I ended up tweaking a few KDE cache settings that pointed at /var/tmp by default, to point somewhere in /home instead, for instance. Ask if you want the details.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
