[gentoo-amd64] Re: Symlinks vs. Bind mounts.

[Duncan]

"Juan Fco. Giordana" <juangiordana@×××××.com> posted
48A1034E.5030109@×××××.com, 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