[gentoo-amd64] Symlinks vs. Bind mounts.

[gentoo-amd64] Symlinks vs. Bind mounts.

[Juan Fco. Giordana]

Hello list,

I've been reading a lot about filesystems and tunning Gentoo to make it 
perform faster and more efficiently.

I've been using a combination of what D. Robbnins explains in his 
articles. Basically a separate "reiserfs" partition mounted in 
"/mnt/rwstrg" that contains "portage, src, var and tmp" as explained here:

http://www.funtoo.org/en/articles/linux/partitioning/2/

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).

The only thing that makes me follow the same path for /usr/src is also
manageability.

I've been googling a lot about this with no success trying to find out 
what would be better (faster), if using symbolic links or bind mounts. I 
also mailed Mr. Robbins but haven't received an answer and honestly I 
don't I will.

I'm not a guru on the field, I've read somewhere that using symbolic
links has its drawbacks because the applications have to map to the 
proper file/dir location on every access (and I never liked them).

Hope someone could guide me with this.

Thanks.

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

[Duncan]

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

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

[Morgan Wesström]

Duncan wrote:
> 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.

This advice caught my attention since I moved my tmp space to Reiserfs 
for performance reasons. My knowledge of tmpfs is limited but I think it 
is a filesystem that uses RAM and can grow and shrink dynamically, 
right? If I follow this advice, what happens when I compile something 
like Open Office which allocates 3-4GB in /var/tmp during compilation 
and I only have 2GB physical RAM in the computer?

Regards
Morgan

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

[Juan Fco. Giordana]

Morgan Wesström wrote:
> If I follow this advice, what happens when I compile something like
> Open Office which allocates 3-4GB in /var/tmp during compilation and
> I only have 2GB physical RAM in the computer?

If all the Virtual Memory (VM = RAM+SWAP) is exhausted the kernel will 
try to kill the process that is consuming most of it. Daniel Robbins 
explains precisely that behaviour in this article:

http://www.funtoo.org/en/articles/linux/ffg/3/

"So, the kernel mistakenly attacks the biggest VM-hog of a process it 
can find, which is generally your X server if you happen to be running 
one. So, your X server dies, and the root cause of the low-VM condition 
(tmpfs) isn't addressed. Ick."

See "Avoiding low VM conditions".

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

[Beso]

[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]

2008/8/12 Juan Fco. Giordana <juangiordana@gmail.com>

> Morgan Wesström wrote:
>
>> If I follow this advice, what happens when I compile something like
>> Open Office which allocates 3-4GB in /var/tmp during compilation and
>> I only have 2GB physical RAM in the computer?
>>
>
> If all the Virtual Memory (VM = RAM+SWAP) is exhausted the kernel will try
> to kill the process that is consuming most of it. Daniel Robbins explains
> precisely that behaviour in this article:
>
> http://www.funtoo.org/en/articles/linux/ffg/3/
>
> "So, the kernel mistakenly attacks the biggest VM-hog of a process it can
> find, which is generally your X server if you happen to be running one. So,
> your X server dies, and the root cause of the low-VM condition (tmpfs) isn't
> addressed. Ick."
>
> See "Avoiding low VM conditions".
>
>
if you're still using something the kernel won't kill nothing. the behaviour
you're referencing is the kernel cached pages. when you use something you
load it into memory. after you finish using it then the kernel will continue
to hold the pages in ram as cached pages, if you have enough space to be
able to speed up the eventual future reuse of that particular object. when
the ram is over certain quota the kernel will free some pages based on
different criteria like the oldness of the page or on how many times that
particular page has been used. for example if you use libdvdcss to decode a
dvd you'll have it in ram. let's assume that you then load another library
and use that library 30 times. then you'll reuse libdvdcss again and then
start a program that will consume quite some ram space, like openoffice. the
kernel will free the libdvdcss from ram and cache it into the swap partition
mantaining the other library into ram if possible, cause it has been used
more than once. this is a mere and very simple example of how the kernel
frees the ram space.
as for processes that are in use, from my knowledge, the kernel will not
kill anything unless the process doesn't reply to its interrupts.

-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 2696 bytes --]

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

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560808120130o55c0c805n69bda3ed4cb9a823@mail.gmail.com, excerpted
below, on  Tue, 12 Aug 2008 08:30:44 +0000:

> if you're still using something the kernel won't kill nothing. the
> behaviour you're referencing is the kernel cached pages. when you use
> something you load it into memory. after you finish using it then the
> kernel will continue to hold the pages in ram as cached pages, if you
> have enough space to be able to speed up the eventual future reuse of
> that particular object.

Beso, I think he was referring to being totally out of memory+swap, thus 
triggering the kernel OOM (out of memory) killer.

Yes, that can happen.  However, in practice, at least from my experience, 
before the kernel ever gets to the point of actually killing anything, 
the system becomes basically unresponsive anyway, as the kernel searches 
for every last bit of memory it can recover to use for whatever is taking 
it all.  I've never had that happen since I switched to /tmp on tmpfs so 
I don't know how it works in regard to that -- presumably it'd consider 
it temporary and kill it before killing applications, but I don't know 
that for sure -- but I did have it happen once when I had swap turned off 
and only a gig of memory -- and tried to scan something at an incredibly 
high resolution that would have used over a gig of memory for the scan 
data alone, had I had it there to use!  Even with swap turned off, the 
system was unusable, as the kernel was still looking for every bit of 
memory it could find some 15 minutes or so into unresponsiveness, when I 
gave up and hit the reset.  I don't know how much longer it would have 
continued before triggering the OOM killer, but it wasn't worth waiting 
around to find out.

BTW, I did have a runaway process once some-time later (before I set 
system per-process memory limits using ulimit, see "help ulimit" at the 
bash prompt), after I had upgraded to 8 gigs RAM, with 16 gigs swap as 4 
partitions of 4 gigs each, on 4 different hard drives (with priority set 
equal so the kernel striped them for 4X swap speed).  That worked much 
better as I didn't let it get quite out of memory before killing it, but 
I did let the process go long enough to have it eat up the 8 gigs of 
regular memory plus 15 gigs or so of swap before I killed it, just to see 
how responsive the system remained while nearly 16 gigs into swap after I 
had 4-way striped it.  The system was a bit draggy at that, but it was 
certainly WAY more responsive than that time I let it get totally out of 
memory with NO swap, and responsive enough that I could still kill the 
runaway process when I decided it was getting too close to leaving me in 
the same situation again.  (While I let it run until 15 out of 16 gigs 
swap were used, I had setup a high priority root shell with the kill -9 
command waiting for me to hit enter... before it got far into swap, just 
in case.)  I'd have hated to have been 16 gigs into swap on a single-
spindle swap system, that's for sure!

So anyway, make sure you have enough memory+swap to compile OOo, and you 
shouldn't have any major problems.  FWIW, I set my max capacity on the 
tmpfs to 6 GB, since I knew OOo took 5+ gigs as the largest package, tho 
I've never actually compiled it.  And of course with 8 gigs RAM and 16 
gigs swap, I have 24 gigs mem+swap to play with, and the 6 gig max tmpfs 
doesn't get anywhere near that, so I'm fine. 

BTW, Chris G, one of the devs in the game herd, has mentioned that there 
are a couple game-data packages that actually require more scratch-space 
to merge than OOo, but of course they aren't compiled, so if the system 
runs out of room installing them, no big deal, just create a sufficiently 
large temporary swap file or switch PORTAGE_TMPDIR back to disk 
temporarily, and retry.  It's not like you're losing hours of work like 
would be possible if OOo ran out of room while emerging.  Plus at least 
personally, I don't have to worry about that since the games in question 
aren't freedomware anyway, so I'd never install them in the first place.

-- 
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

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

[Beso]

[-- Attachment #1: Type: text/plain, Size: 4573 bytes --]

2008/8/12 Duncan <1i5t5.duncan@cox.net>

> Beso <givemesugarr@gmail.com> posted
> d257c3560808120130o55c0c805n69bda3ed4cb9a823@mail.gmail.com, excerpted
> below, on  Tue, 12 Aug 2008 08:30:44 +0000:
>
> > if you're still using something the kernel won't kill nothing. the
> > behaviour you're referencing is the kernel cached pages. when you use
> > something you load it into memory. after you finish using it then the
> > kernel will continue to hold the pages in ram as cached pages, if you
> > have enough space to be able to speed up the eventual future reuse of
> > that particular object.
>
> Beso, I think he was referring to being totally out of memory+swap, thus
> triggering the kernel OOM (out of memory) killer.
>
> Yes, that can happen.  However, in practice, at least from my experience,
> before the kernel ever gets to the point of actually killing anything,
> the system becomes basically unresponsive anyway, as the kernel searches
> for every last bit of memory it can recover to use for whatever is taking
> it all.  I've never had that happen since I switched to /tmp on tmpfs so
> I don't know how it works in regard to that -- presumably it'd consider
> it temporary and kill it before killing applications, but I don't know
> that for sure -- but I did have it happen once when I had swap turned off
> and only a gig of memory -- and tried to scan something at an incredibly
> high resolution that would have used over a gig of memory for the scan
> data alone, had I had it there to use!  Even with swap turned off, the
> system was unusable, as the kernel was still looking for every bit of
> memory it could find some 15 minutes or so into unresponsiveness, when I
> gave up and hit the reset.  I don't know how much longer it would have
> continued before triggering the OOM killer, but it wasn't worth waiting
> around to find out.
>
> BTW, I did have a runaway process once some-time later (before I set
> system per-process memory limits using ulimit, see "help ulimit" at the
> bash prompt), after I had upgraded to 8 gigs RAM, with 16 gigs swap as 4
> partitions of 4 gigs each, on 4 different hard drives (with priority set
> equal so the kernel striped them for 4X swap speed).  That worked much
> better as I didn't let it get quite out of memory before killing it, but
> I did let the process go long enough to have it eat up the 8 gigs of
> regular memory plus 15 gigs or so of swap before I killed it, just to see
> how responsive the system remained while nearly 16 gigs into swap after I
> had 4-way striped it.  The system was a bit draggy at that, but it was
> certainly WAY more responsive than that time I let it get totally out of
> memory with NO swap, and responsive enough that I could still kill the
> runaway process when I decided it was getting too close to leaving me in
> the same situation again.  (While I let it run until 15 out of 16 gigs
> swap were used, I had setup a high priority root shell with the kill -9
> command waiting for me to hit enter... before it got far into swap, just
> in case.)  I'd have hated to have been 16 gigs into swap on a single-
> spindle swap system, that's for sure!
>
> So anyway, make sure you have enough memory+swap to compile OOo, and you
> shouldn't have any major problems.  FWIW, I set my max capacity on the
> tmpfs to 6 GB, since I knew OOo took 5+ gigs as the largest package, tho
> I've never actually compiled it.  And of course with 8 gigs RAM and 16
> gigs swap, I have 24 gigs mem+swap to play with, and the 6 gig max tmpfs
> doesn't get anywhere near that, so I'm fine.
>
> BTW, Chris G, one of the devs in the game herd, has mentioned that there
> are a couple game-data packages that actually require more scratch-space
> to merge than OOo, but of course they aren't compiled, so if the system
> runs out of room installing them, no big deal, just create a sufficiently
> large temporary swap file or switch PORTAGE_TMPDIR back to disk
> temporarily, and retry.  It's not like you're losing hours of work like
> would be possible if OOo ran out of room while emerging.  Plus at least
> personally, I don't have to worry about that since the games in question
> aren't freedomware anyway, so I'd never install them in the first place.
>

does it really worth to compile OOo instead of just downloading the bin
version?! the last time i've tried it the ammount of space taken "hostage",
the slowness of compilation and the really small improvement in speed (as
well as the other deps to install) made me chose the 32bit precompiled bin
package.


dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 5440 bytes --]

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

[Wil Reichert]

On Tue, Aug 12, 2008 at 8:05 AM, Beso <givemesugarr@gmail.com> wrote:
>
>
> 2008/8/12 Duncan <1i5t5.duncan@cox.net>
>>
>> Beso <givemesugarr@gmail.com> posted
>> d257c3560808120130o55c0c805n69bda3ed4cb9a823@mail.gmail.com, excerpted
>> below, on  Tue, 12 Aug 2008 08:30:44 +0000:
>>
>> > if you're still using something the kernel won't kill nothing. the
>> > behaviour you're referencing is the kernel cached pages. when you use
>> > something you load it into memory. after you finish using it then the
>> > kernel will continue to hold the pages in ram as cached pages, if you
>> > have enough space to be able to speed up the eventual future reuse of
>> > that particular object.
>>
>> Beso, I think he was referring to being totally out of memory+swap, thus
>> triggering the kernel OOM (out of memory) killer.
>>
>> Yes, that can happen.  However, in practice, at least from my experience,
>> before the kernel ever gets to the point of actually killing anything,
>> the system becomes basically unresponsive anyway, as the kernel searches
>> for every last bit of memory it can recover to use for whatever is taking
>> it all.  I've never had that happen since I switched to /tmp on tmpfs so
>> I don't know how it works in regard to that -- presumably it'd consider
>> it temporary and kill it before killing applications, but I don't know
>> that for sure -- but I did have it happen once when I had swap turned off
>> and only a gig of memory -- and tried to scan something at an incredibly
>> high resolution that would have used over a gig of memory for the scan
>> data alone, had I had it there to use!  Even with swap turned off, the
>> system was unusable, as the kernel was still looking for every bit of
>> memory it could find some 15 minutes or so into unresponsiveness, when I
>> gave up and hit the reset.  I don't know how much longer it would have
>> continued before triggering the OOM killer, but it wasn't worth waiting
>> around to find out.
>>
>> BTW, I did have a runaway process once some-time later (before I set
>> system per-process memory limits using ulimit, see "help ulimit" at the
>> bash prompt), after I had upgraded to 8 gigs RAM, with 16 gigs swap as 4
>> partitions of 4 gigs each, on 4 different hard drives (with priority set
>> equal so the kernel striped them for 4X swap speed).  That worked much
>> better as I didn't let it get quite out of memory before killing it, but
>> I did let the process go long enough to have it eat up the 8 gigs of
>> regular memory plus 15 gigs or so of swap before I killed it, just to see
>> how responsive the system remained while nearly 16 gigs into swap after I
>> had 4-way striped it.  The system was a bit draggy at that, but it was
>> certainly WAY more responsive than that time I let it get totally out of
>> memory with NO swap, and responsive enough that I could still kill the
>> runaway process when I decided it was getting too close to leaving me in
>> the same situation again.  (While I let it run until 15 out of 16 gigs
>> swap were used, I had setup a high priority root shell with the kill -9
>> command waiting for me to hit enter... before it got far into swap, just
>> in case.)  I'd have hated to have been 16 gigs into swap on a single-
>> spindle swap system, that's for sure!
>>
>> So anyway, make sure you have enough memory+swap to compile OOo, and you
>> shouldn't have any major problems.  FWIW, I set my max capacity on the
>> tmpfs to 6 GB, since I knew OOo took 5+ gigs as the largest package, tho
>> I've never actually compiled it.  And of course with 8 gigs RAM and 16
>> gigs swap, I have 24 gigs mem+swap to play with, and the 6 gig max tmpfs
>> doesn't get anywhere near that, so I'm fine.
>>
>> BTW, Chris G, one of the devs in the game herd, has mentioned that there
>> are a couple game-data packages that actually require more scratch-space
>> to merge than OOo, but of course they aren't compiled, so if the system
>> runs out of room installing them, no big deal, just create a sufficiently
>> large temporary swap file or switch PORTAGE_TMPDIR back to disk
>> temporarily, and retry.  It's not like you're losing hours of work like
>> would be possible if OOo ran out of room while emerging.  Plus at least
>> personally, I don't have to worry about that since the games in question
>> aren't freedomware anyway, so I'd never install them in the first place.
>
> does it really worth to compile OOo instead of just downloading the bin
> version?! the last time i've tried it the ammount of space taken "hostage",
> the slowness of compilation and the really small improvement in speed (as
> well as the other deps to install) made me chose the 32bit precompiled bin
> package.
>
>
> dott. ing. beso
>

Every time you re-install the -bin package you need to re-accept their
license (er whatever, registaration perhaps?) at first run.  Annoys me
enough to compile it myself.

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

[Duncan]

"Wil Reichert" <wil.reichert@gmail.com> posted
7a329d910808120838v1d8d296ft1dcfb2c4073b9ec0@mail.gmail.com, excerpted
below, on  Tue, 12 Aug 2008 08:38:57 -0700:

> Every time you re-install the -bin package you need to re-accept their
> license (er whatever, registaration perhaps?) at first run.  Annoys me
> enough to compile it myself.

Ugh, I've obviously never tried it or I'd have been saying no way, 
myself.  I'd have to see it but normally anything software that has 
anything like that, even registration, is way to much like slaveryware 
for my taste, and it's gone off my system faster than it downloaded in 
the first place!

For awhile imagemagick required MSCorefonts, with a similar EULA/
whatever, and (after I filed a bug) I put the corefonts package in 
package.provided and that was it.  It didn't actually need it anyway, 
except for a specific operation I never tried, at runtime.  Now they 
control that with the truetype USE flag IIRC, so I have it in package.use 
with that flag turned off -- the only package on the system with it 
turned off.

-- 
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

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

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560808120805i181e6810mbe4e284b4bba1662@mail.gmail.com, excerpted
below, on  Tue, 12 Aug 2008 15:05:46 +0000:

> does it really worth to compile OOo instead of just downloading the bin
> version?! the last time i've tried it the ammount of space taken
> "hostage", the slowness of compilation and the really small improvement
> in speed (as well as the other deps to install) made me chose the 32bit
> precompiled bin package.

I wouldn't personally know, as I've never installed any version of it.  I 
do have kspread installed as I needed it to view an MS Excel file awhile 
back, but that's about it.

If I was still running multilib and I needed OOo, I'd probably merge the 
32-bit precompiled, just because I don't consider it worth the trouble, 
here.  However, since I'm running no-multilib now (and haven't regretted 
it yet, rather the opposite as it's less hassle AND less compile time on 
gcc and glibc, among others) and as AFAIK there's no 64-bit precompiled 
version.

But since OOo is GTK based and I'm a KDE (3.x, so far) guy, I'd certainly 
try koffice or its individual components (such as the kspread I already 
have merged) first.  I have GTK installed, but only for pan and now 
firefox, and every once in awhile, I consider switching off of pan and 
back to konqueror exclusively, and killing GTK on my box.  But I haven't 
yet.

-- 
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

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

[Peter Volkov]

В Втр, 12/08/2008 в 15:05 +0000, Beso пишет:
> does it really worth to compile OOo instead of just downloading the
> bin version?! the last time i've tried it the ammount of space taken
> "hostage", the slowness of compilation and the really small
> improvement in speed (as well as the other deps to install) made me
> chose the 32bit precompiled bin package.

In portage tree openoffice source package receives intermediate updates
with patches from upstream (see silent patchset bumps lines in
ChangeLog) which fix many important problems like crashes.
Openoffice-bin misses this fixes. So yes, it's better to build OO from
sources having your hand on ChangeLog and rebuild it when update
comes... Another alternative is to use updated binary snapshots from
upstream, but I don't know where you can download them.

-- 
Peter.

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

[Matthias Bethke]

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

Hi Juan,
on Tue, Aug 12, 2008 at 05:18:53AM -0300, you wrote:
>> If I follow this advice, what happens when I compile something like
>> Open Office which allocates 3-4GB in /var/tmp during compilation and
>> I only have 2GB physical RAM in the computer?
>
> If all the Virtual Memory (VM = RAM+SWAP) is exhausted the kernel will try 
> to kill the process that is consuming most of it.

That's why tmpfs also uses swapspace. Given the address space you have
on a 64bit system, I don't see any reason[0] to save swapspace any
more---after I tried the tmpfs idea for the first time, I just
repartitioned my system for 32 GiB of swap and put /tmp and
/var/tmp/portage on tmpfs. Just perfect.
Not only does this speed up everything that uses temporary files, it
also minimizes the effect of programs that fragment or leak their
memory, like FF2 that had a habit of packing small cached things after
big ones and then not reusing the big ones after they had been freed and
thus ballooning to perverse sizes. I've seen a Firefox grow to over 10
GiB (at 4 GB physical RAM) with minimal impact on the rest of the system
because the hardly ever touched pages just get paged out at some point
and don't matter as long as they stay on disk.

cheers,
	Matthias

[0] OK, there is small overhead due to larger page tables but it's
negligible.
-- 
I prefer encrypted and signed messages. KeyID: FAC37665
Fingerprint: 8C16 3F0A A6FC DF0D 19B0  8DEF 48D9 1700 FAC3 7665

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Beso]

[-- Attachment #1: Type: text/plain, Size: 2596 bytes --]

2008/8/12 Morgan Wesström <gentoo-amd64@pp.dyndns.biz>

> Duncan wrote:
>
>> 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.
>>
>
> This advice caught my attention since I moved my tmp space to Reiserfs for
> performance reasons. My knowledge of tmpfs is limited but I think it is a
> filesystem that uses RAM and can grow and shrink dynamically, right? If I
> follow this advice, what happens when I compile something like Open Office
> which allocates 3-4GB in /var/tmp during compilation and I only have 2GB
> physical RAM in the computer?
>

you'll use swap partition. but you'll not allocate all that ram space with
openoffice. i've tried to compile it twice. first time it was on disk and it
took almost 14 hours of compilation. the second time was on tmpfs with 3.8gb
and a 6gb swap file and it took less than 8 hours and i've never filled the
swap partition. to put at maximum use this method with low ram then don't
start xorg and graphical terminals but only the base vt and compile from
there. this will save you quite some ram space. you'll also find that the -j
option in your make.conf could be increased much when going with tmpfs. for
example i've passed from -j5 in hd use to -j9 in tmpfs and i still have a
very good and usable graphical system. with the old single core pc i was
using -j2 in hd and -j5 on tmpfs. this dramattically decreases compilation
time.

@duncan: do you remember that some time ago you were speaking about posting
the scripts to compile the kernel with the make.conf optimizations, but you
haven't posted them any more. do you still use them?!

-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 3096 bytes --]

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

[Morgan Wesström]

> you'll use swap partition. but you'll not allocate all that ram space 
> with openoffice. i've tried to compile it twice. first time it was on 
> disk and it took almost 14 hours of compilation. the second time was on 
> tmpfs with 3.8gb and a 6gb swap file and it took less than 8 hours and 

If I understand you correctly, I wouldn't be able to compile Open Office 
on tmpfs with my 2GB RAM and 1GB swap. I would have to increase the swap 
space to be able to hold all the temporary files from the compilation, 
wouldn't I?
/Morgan

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

[Beso]

[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]

2008/8/12 Morgan Wesström <gentoo-amd64@pp.dyndns.biz>

> you'll use swap partition. but you'll not allocate all that ram space with
>> openoffice. i've tried to compile it twice. first time it was on disk and it
>> took almost 14 hours of compilation. the second time was on tmpfs with 3.8gb
>> and a 6gb swap file and it took less than 8 hours and
>>
>
> If I understand you correctly, I wouldn't be able to compile Open Office on
> tmpfs with my 2GB RAM and 1GB swap. I would have to increase the swap space
> to be able to hold all the temporary files from the compilation, wouldn't I?
> /Morgan
>
>
well, it's difficult to compile it and in my opinion you might be able to do
it, but i'm not sure. also be aware that usually the tmpfs is lower than
1gb. do a df /tmp and see yourself. you should specify your tmpfs size in
/etc/fstab like in the following example:

tmpfs                   /tmp            tmpfs
mode=1777,size=8G,nodev,nosuid  0 0

the example puts the right tmpfs permissions and sets the size of it to 8GB.
i currently have 3.8gb of ram and 8gb of swap. this means that i still have
plenty of room in the swap and ram to be able to run smoothly the system.
usually the swap partition is put to a dimension equal to double the ram
dimension. if you want to compile into ram you should set it to more than
double, for example to about 3 times the ram space, thus equal to 6gb and
then set the maximum tmpfs in fstab to 6gb or even 7gb. in this way you'll
use first all of your ram and then till 4 or 5 gb of swap. this will allow
your pc to respond even if the compilation will go over the estimated space.

-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 2454 bytes --]

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

[Peter Humphrey]

On Tuesday 12 August 2008 10:22:56 Morgan Wesström wrote:

> If I understand [...] correctly, I wouldn't be able to compile Open Office
> on tmpfs with my 2GB RAM and 1GB swap. I would have to increase the swap
> space to be able to hold all the temporary files from the compilation,
> wouldn't I?

Yes. In fact, the OOo installation process checks for sufficient space 
before it starts, both RAM and swap, and stops if it thinks you haven't 
enough.

You could always allocate another swap partition. One of my boxes has 4 2GB 
partitions on different disks, though that's far more than I need.

-- 
Rgds
Peter

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

[Matthias Bethke]

[-- Attachment #1: Type: text/plain, Size: 627 bytes --]

Hi Peter,
on Tue, Aug 12, 2008 at 11:04:13AM +0100, you wrote:
> You could always allocate another swap partition. One of my boxes has 4 2GB 
> partitions on different disks, though that's far more than I need.

You still get the benefit of automatic striping so if they're on
independent channels you have roughly four times the swap throughput.
I have two 500G disks, mirrored in a software-RAID0 on all partitions
but swap which is on two separate 16G partitions.

cheers,
	Matthias

-- 
I prefer encrypted and signed messages. KeyID: FAC37665
Fingerprint: 8C16 3F0A A6FC DF0D 19B0  8DEF 48D9 1700 FAC3 7665

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Duncan]

Matthias Bethke <matthias@towiski.de> posted 20080813225448.GM7990@aldous,
excerpted below, on  Thu, 14 Aug 2008 00:54:48 +0200:

> I have two 500G disks, mirrored in a software-RAID0 on all partitions
> but swap which is on two separate 16G partitions.

OK, if it's RAID-0, it's striped, not mirrored, and you have NO 
redundancy at all.  If either of those disks fails, your SOL.

If it's mirrored, you meant RAID-1.

I might have let it pass, but if you think you're mirrored (RAID-1) and 
are striped (RAID-0) instead, you could be in for one NASTY surprise if 
one of the disks dies.  So I thought it wise to post and warn you, just 
in case it WASN'T just a typo and you screwed up, BEFORE something 
happens and you lose the data.

But you're correct about swap, at least if you have them set at the same 
priority.  The kernel will automatically stripe across all swap 
partitions set at the same priority, so if you have multiple disks, put a 
swap partition on each and set the priority equal (in fstab if you 
automate swap loading from there), and the kernel will automatically 
stripe them, increasing your swap performance accordingly. =8^)

-- 
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

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

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]

Duncan wrote:
> 
> But you're correct about swap, at least if you have them set at the same 
> priority.  The kernel will automatically stripe across all swap 
> partitions set at the same priority, so if you have multiple disks, put a 
> swap partition on each and set the priority equal (in fstab if you 
> automate swap loading from there), and the kernel will automatically 
> stripe them, increasing your swap performance accordingly. =8^)
> 

Note that in such a situation if either disk fails you're likely to end 
up with a panic when your swap device isn't accessible.  If uptime is a 
concern mirrored swap is better (but slower).

Of course, if you're running on consumer hardware chances are that 
computer is going to fail if a drive hangs up in any case - most 
motherboards don't handle drive failures gracefully, but server-class 
hardware usually isolates drives so that a drive failure doesn't take 
down the system.

If the bulk of your data is mirrored you'll get everything back on 
reboot after removing the bad drive.  However, you will likely lose 
anything in memory.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3670 bytes --]

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

[Matthias Bethke]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

Hi Richard,
on Thu, Aug 14, 2008 at 02:08:26PM -0400, you wrote:
> Note that in such a situation if either disk fails you're likely to end up 
> with a panic when your swap device isn't accessible.  If uptime is a 
> concern mirrored swap is better (but slower).
>
> Of course, if you're running on consumer hardware chances are that computer 
> is going to fail if a drive hangs up in any case - most motherboards don't 
> handle drive failures gracefully, but server-class hardware usually 
> isolates drives so that a drive failure doesn't take down the system.

True, that's a risk I figured I could live with. It's actually a server
board but in a regular tower case and w/o hot-swappable drives, and I'm
not controlling my iron lung with it :)

cheers,
	Matthias
-- 
I prefer encrypted and signed messages. KeyID: FAC37665
Fingerprint: 8C16 3F0A A6FC DF0D 19B0  8DEF 48D9 1700 FAC3 7665

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Duncan]

Richard Freeman <rich@thefreemanclan.net> posted
48A4749A.60509@thefreemanclan.net, excerpted below, on  Thu, 14 Aug 2008
14:08:26 -0400:

> Duncan wrote:
>> 
>> But you're correct about swap[...] at the same priority
>> 
> Note that in such a situation if either disk fails you're likely to end
> up with a panic when your swap device isn't accessible.  If uptime is a
> concern mirrored swap is better (but slower).

Correct.  However, I'm not too worried about a crash.  In fact, I don't 
even have a UPS here, tho it's on my list again now that I switched to 
LCDs from CRTs.  

> If the bulk of your data is mirrored you'll get everything back on
> reboot after removing the bad drive.  However, you will likely lose
> anything in memory.

That's the plan.  As long as I don't lose the data on the RAID-6 (and 
RAID-1, to boot with), I'm fine.  I don't have a spare drive to repair to 
either, tho I could buy one relatively quickly if necessary.  But I did 
deliberately choose RAID-6 with double redundancy over RAID-5 with single 
redundancy and a "hot-spare".

Of course, if three of the four go out before I can get at least one 
repaired, I'm still SOL, but that's a chance I'm willing to take, and a 
serious improvement over the backup-copy-on-a-different-partition-on-the-
same-spindle scheme I was using before.  It's only my hobby, after all, 
not holding a month or year's income dependency, and if I had that many 
drives die at once, chances are I'd have bigger problems, and would be 
looking at buying a whole new computer, and possibly a whole new house, 
anyway.

-- 
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

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

[Matthias Bethke]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

Hi Duncan,
on Thu, Aug 14, 2008 at 08:07:40AM +0000, you wrote:
> > I have two 500G disks, mirrored in a software-RAID0 on all partitions
> > but swap which is on two separate 16G partitions.
> 
> OK, if it's RAID-0, it's striped, not mirrored, and you have NO 
> redundancy at all.  If either of those disks fails, your SOL.
> 
> If it's mirrored, you meant RAID-1.

Ouch---you're right of course, it's RAID-1. Not the first time I
confused the two but the setup is indeed mirrored ;)

cheers,
	Matthias

-- 
I prefer encrypted and signed messages. KeyID: FAC37665
Fingerprint: 8C16 3F0A A6FC DF0D 19B0  8DEF 48D9 1700 FAC3 7665

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Peter Humphrey]

On Wednesday 13 August 2008 23:54:48 Matthias Bethke wrote:
> Hi Peter,
>
> on Tue, Aug 12, 2008 at 11:04:13AM +0100, you wrote:
> > You could always allocate another swap partition. One of my boxes has 4
> > 2GB partitions on different disks, though that's far more than I need.
>
> You still get the benefit of automatic striping so if they're on
> independent channels you have roughly four times the swap throughput.

I've read somewhere that for maximum speed you need to set equal priorities 
on the swap partitions in fstab, so that 'defaults' gets replaced 
with 'pri=1' (or some other number, as long as it's the same for all).

> I have two 500G disks, mirrored in a software-RAID0 on all partitions
> but swap which is on two separate 16G partitions.

Similar to mine, apart from the sizes, but I also have a couple of IDE disks 
with swap partitions on them.

-- 
Rgds
Peter

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

[Adam Mooz]

[-- Attachment #1: Type: text/plain, Size: 229 bytes --]

>
> Similar to mine, apart from the sizes, but I also have a couple of IDE
> disks
> with swap partitions on them.
>

This is the method I use; an old 8-40GB IDE drive on it's own channel for
swap.  (all my drives are SATA now.)

[-- Attachment #2: Type: text/html, Size: 476 bytes --]

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

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560808120123t4733d15pc81f4968cbba9bdf@mail.gmail.com, excerpted
below, on  Tue, 12 Aug 2008 08:23:06 +0000:

> 2008/8/12 Morgan Wesström <gentoo-amd64@pp.dyndns.biz>
> 
>> Duncan wrote:
>>
>>> Now, if you /really/ want to make a difference in portage's speed,
>>> consider pointing PORTAGE_TMPDIR at a tmpfs.
>>>
>> This advice caught my attention since I moved my tmp space to Reiserfs
>> for performance reasons. My knowledge of tmpfs is limited but I think
>> it is a filesystem that uses RAM and can grow and shrink dynamically,
>> right? If I follow this advice, what happens when I compile something
>> like Open Office which allocates 3-4GB in /var/tmp during compilation
>> and I only have 2GB physical RAM in the computer?
>>
> you'll use swap partition. but you'll not allocate all that ram space
> with openoffice. i've tried to compile it twice. first time it was on
> disk and it took almost 14 hours of compilation. the second time was on
> tmpfs with 3.8gb and a 6gb swap file and it took less than 8 hours and
> i've never filled the swap partition. to put at maximum use this method
> with low ram then don't start xorg and graphical terminals but only the
> base vt and compile from there. this will save you quite some ram space.
> you'll also find that the -j option in your make.conf could be increased
> much when going with tmpfs. for example i've passed from -j5 in hd use
> to -j9 in tmpfs and i still have a very good and usable graphical
> system. with the old single core pc i was using -j2 in hd and -j5 on
> tmpfs. this dramattically decreases compilation time.

This well illustrates the speed-up of PORTAGE_TMPDIR on tmpfs.  Now, I 
don't use -j -l MAKEOPTS to control load so much as to control memory 
usage.  I can have a load in the hundreds and it doesn't matter that 
much, particularly with per-user scheduling turned on in the kernel, but 
of course memory can still be an issue if compiling into tmpfs and too 
many jobs get going.

I'll second that tmpfs is swappable as well.  That makes it great for 
compiling (as long as you have enough swap), because even when real 
memory isn't enough to hold it all and it swaps some of it, many of the 
shortest lived files never hit disk at all, making it MUCH faster, and, 
as Beso points out, MUCH more responsive on other things as well, even 
with more jobs going, because of the nature of disk I/O.

Morgan also asks (down-thread) about compiling OOo with 2 gig RAM and 1 
gig swap.  Yes, that'll be problematic.  One thing you could do would be 
to shrink or kill entirely the partition you are using for /tmp and/or 
/var/tmp (or wherever else you are currently compiling OOo into that 
obviously has that much space) and turn it into more swap.  Another 
alternative is to setup swap files.  With 3 gigs total mem+swap, if you 
don't want any more swap under normal conditions, this would allow you to 
create it temporarily out of normal filesystem space, only for merging 
big stuff like OOo.  It won't be quite as fast that way, but it should 
still be way faster than compiling it to PORTAGE_TMPDIR on disk.  A third 
alternative would be to point PORTAGE_TMPDIR at tmpfs for normal merges, 
and just point it back at disk temporarily when emerging OOo.  Of course, 
that would be slow again, but no slower than now, and you'd still have 
the speedup when merging most stuff.

Personally, I'd recommend the first, recovering disk space currently used 
for /tmp or /var/tmp, and turning it into swap.

> @duncan: do you remember that some time ago you were speaking about
> posting the scripts to compile the kernel with the make.conf
> optimizations, but you haven't posted them any more. do you still use
> them?!

I remember, and yes, I'm still using them.  I had to fix something 
recently, when debianutils changed its kernel install scripts, but I 
still use them.

I still have to get it on the webspace, but thanks for reminding me.

-- 
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