# do gentoo/compiling harm ssd's?

## LoTeK

I've just read about why some people change from gentoo to arch (for those who understand german:

http://www.hardwareluxx.de/community/f211/gentoo-linux-oder-arch-linux-783591.html

that compiling alot harms ssd and that gentoo generally has to much writes to the harddrive... is this true?

anyway I don't understand why so many people complain about compile-time, one can do other things while compiling... for me the "compile everything yourself philosophy" was my main reason to change from mint/arch/fedora to gentoo... not even because it should run faster, but because it's cooler and "realer"   :Very Happy: 

----------

## NeddySeagoon

LoTeK,

In the early days of FLASH memories, write cycle life expectancy was about 1000 cycles. There was no wear leveling and the devices were too small and expensive to even think about using them is solid state drives.

Write life expectancy has improved, wear leveling exists, device capacity has increased and cost has plummeted.

There is anecdotal evidence on these forums that attempting to install Gentoo on the early 4G SSDs fitted to the eeepc would kill the drive before the install was complete.

Its no longer an issue.

----------

## LoTeK

NeddySeagon, 

ok, good to hear that...

but is life expectancy still lower then the one of conventional harddrives? on my T420s I only have one 160GB SSD, but on my workstation I have a 128GB SSD and a 2TB HDD. Is it still a good idea to put /var and /tmp on the HDD for this reason? because now I have lvm2 with an extended volume group containing /home /var /tmp /opt and as far as I know I can't control if /var and /tmp are completely on the hdd

----------

## alkan

if you have enough memory(RAM), you can put the 'var/tmp' on a tmpfs. That would reduce the writes to the SSD. Compile times are also faster  as a side benefit.

----------

## NeddySeagoon

LoTeK,

I have /tmp and /var/tmp/portage in RAM.

/tmp should only be small.  If you need to put a DVD iso file somewhere before you burn it, /tmp is not the place. Somewhere in ./~ is better.

----------

## logical_guy

can you post your fstab, neddy?

----------

## LoTeK

On the workstation I have 16G, so I can do it there, but I guess 4G is too small, although the 4 gigs are seldom working at full capacity I need sometimes everything...

my /tmp size is 10G.Last edited by LoTeK on Sun Nov 18, 2012 1:07 am; edited 1 time in total

----------

## Hypnos

Memory is allocated to the tmpfs only as it's needed.  So you'll only run into a problem if you're emerging something big and doing memory-intensive work at the same time.

I have /var/tmp/paludis on tmpfs (2560 Mib limit), and leave /tmp on the SSD since it gets few writes anyway compared to my home directory.

----------

## cach0rr0

 *LoTeK wrote:*   

> but I guess 4G is too small

 

for most things, no

but for things like Thunderbird, Firefox, libreoffice/openoffice, Chromium, yes, that will be too small.

----------

## NeddySeagoon

logical_guy,

Are you sure ?

```

# <fs>                  <mountpoint>    <type>          <opts>          <dump/pass>

# NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.

#/dev/md125             /boot           ext2            noauto,noatime  1 2

UUID=741183c2-1392-4022-a1d3-d0af8ba4a2a8 /boot           ext2            noauto,noatime  1 2

# was /dev/md5 but SystemRescueCD changed minor numbers

# root now md126

UUID=ff5730d5-c28d-4276-b300-5b0b0fc60300               /               ext3            noatime         0 1

/dev/sda2               none            swap            sw              0 0

/dev/sdb2               none            swap            sw              0 0

/dev/sdc2               none            swap            sw              0 0

/dev/sdd2               none            swap            sw              0 0

/dev/cdrom              /mnt/cdrom      udf,iso9660     users,noauto,ro 0 0

/dev/cdrom1             /mnt/floppy     udf,iso9660     users,noauto,ro 0 0

/dev/sr0                /mnt/cdrom      udf,iso9660     users,noauto,ro 0 0

/dev/sr1                /mnt/floppy     udf,iso9660     users,noauto,ro 0 0

#/dev/fd0               /mnt/floppy     auto            noauto          0 0

###########################################################################

# LVM2 mounts #

###############

#/dev/vg/home      /home                   ext4  noatime         1 2

#/dev/vg/opt       /opt                    ext4  noatime         1 2

UUID=8d5d5691-ceb7-4e58-bed3-28803cb88bfe /home                   ext4  noatime         1 2

UUID=7f0fad34-6130-42d8-8246-033de9717005 /opt                    ext4  noatime         1 2

# Warning mounting /tmp noexec is a good idea but breaks nvidia-drivers

#/dev/vg/tmp       /tmp                    ext2  noatime,nodev,nosuid           1 2

UUID=82c29f88-8223-4802-8c66-e18371ba2386       /tmp                    ext2  noatime,nodev,nosuid            1 2

# check order set to zero as the initrd does the checking now

# using real /dev names as the /dev/vg/symlinks are not created in the initrd

# we could just make them 

#/dev/dm-3       /var                    ext4  noatime,noauto    1 0

#/dev/dm-0       /usr                    ext4  noatime,noauto    1 0

UUID=57b34894-f80d-47ab-a522-46fb6e1a19b8 /var                    ext4  noatime,noauto    1 0

UUID=fc23601b-e2af-443f-959e-50148154a91b /usr                    ext4  noatime,noauto    1 0

#/dev/vg/local     /usr/local              ext4  noatime         1 2

#/dev/vg/portage   /usr/portage            ext2  noatime         1 2

#/dev/vg/distfiles /usr/portage/distfiles  ext4  noatime         1 2

#/dev/vg/packages  /usr/portage/packages   ext4  noatime         1 2

UUID=7e0d0ae4-2c57-44e9-995f-5723ab0670b3 /usr/local              ext4  noatime         1 2

UUID=8675cb9c-4251-489f-8e9b-0244ca80176c /usr/portage            ext2  noatime         1 2

UUID=54b46458-d411-4ea8-8920-4c5fcdb56a81 /usr/portage/distfiles  ext4  noatime         1 2

UUID=59c06fd1-8471-4efb-b055-8f1cfb39645f /usr/portage/packages   ext4  noatime         1 2

# vmware is removed, so don't need its space 

#/dev/vg/vmware    /mnt/vmware            ext4  noatime         1 2

# build in RAM

/dev/shm        /var/tmp/portage        tmpfs   noatime,nodev,nosuid    0 0

# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for 

# POSIX shared memory (shm_open, shm_unlink).

# (tmpfs is a dynamically expandable/shrinkable ramdisk, and will

#  use almost no memory if not populated with files)

shm                     /dev/shm        tmpfs           nodev,nosuid,noexec     0 0
```

Hmm, it looks like I forgot to fix /tmp in /etc/fstab after I tested with /tmp in RAM.

I have a 4 spindle RAID.  /boot is raid1, / is raid5 and everything else is in lvm2 on top of raid5.

When I set this box up I wimped out of root in lvm2 on raid but then udev caught up with me and separate /usr and /var.

----------

## LoTeK

 *Quote:*   

> Memory is allocated to the tmpfs only as it's needed. So you'll only run into a problem if you're emerging something big and doing memory-intensive work at the same time. 

 

then I'll give it a try..

----------

## lexming

My laptop is more than three years old and from day one it only has had one 128GB SSD drive in it. I use it everyday at work and home. No problems so far. So, IMO, the last of your problems on a desktop or laptop will be reaching the limit of writes of your drive. Most probably the machine will become obsolete before the SSD fails.

I do my compiling on RAM (but mainly because of the time gain). As cach0rr0 said, 4GB are not enough for everything. But in portage you can set different PORTAGE_TMPDIR for different packages. For example, I have the regular /var/tmp/portage in RAM to compile everything except Firefox and LibreOffice, which are compiled in /var/bigtmp that is located on the SSD.

This can be done through the /etc/portage/package.env. Here is my setup:

```
 $ cat /etc/portage/package.env 

app-office/libreoffice nozram.conf

www-client/firefox nozram.conf
```

```
 $ cat /etc/portage/env/nozram.conf 

PORTAGE_TMPDIR="/var/bigtmp"
```

----------

## eccerr0r

I also currently run Gentoo on SSDs, have three machines with SSD primary disks (32GB SSD/2GB RAM, 128GB SSD/4GB RAM and 180GB SSD/8GB RAM).  I did not however do a full install from stage3, they were "stage4" type installs from a hard drive.  I have the portage tree installed on the >100G disks.

However they all have gone through pretty much an "emerge -e world" because of the number of updates since first install.

I did find something interesting on my Crucial 128GB SSD - it records the average number of times the SSD cells have been erased.  It currently is "3" (of 3000) and this includes the usage on the Windows partitions...  It does not appear to be incrementing way too quickly despite the emerge updates, probably around 1 per month so far.

I tend to compile in tmpfs due to speed too, but when I run out of RAM I just let it go on the SSD.  So far so good, and I even compile firefox (Libreoffice I use the binaries).

(I still have the 4GB SSD that came with my eeePC.  It's too small to do anything really, I wonder how many write cycles it has left.  The 4GB SSD was replaced with the 32GB SSD.  I keep portage on an 8GB SD card, which I expect to fail much sooner than the 32GB...)

----------

## cach0rr0

 *eccerr0r wrote:*   

> I also currently run Gentoo on SSDs, have three machines with SSD primary disks (32GB SSD/2GB RAM, 128GB SSD/4GB RAM and 180GB SSD/8GB RAM).  I did not however do a full install from stage3, they were "stage4" type installs from a hard drive.  I have the portage tree installed on the >100G disks.
> 
> However they all have gone through pretty much an "emerge -e world" because of the number of updates since first install.
> 
> I did find something interesting on my Crucial 128GB SSD - it records the average number of times the SSD cells have been erased.  It currently is "3" (of 3000) and this includes the usage on the Windows partitions...  It does not appear to be incrementing way too quickly despite the emerge updates, probably around 1 per month so far.
> ...

 

sounds like things are more or less sorted with the wear leveling side of things

I'm still wanting to make the SSD jump, and that was one of them, but man...I need crypto, and they still don't seem to have a great answer for that. 

I may be forever stuck rotational

----------

## Hypnos

 *cach0rr0 wrote:*   

> I'm still wanting to make the SSD jump, and that was one of them, but man...I need crypto, and they still don't seem to have a great answer for that. 

 

Well, luks TRIM passthrough works, though zeroed erase blocks do reveal something about the encrypted partition.  You have to decide how valuable your information is.

In my case, I just don't want a common thief to effect an identity theft if they take my laptop, so I just use the hard disk hardware password.

----------

## cach0rr0

 *Hypnos wrote:*   

> 
> 
> Well, luks TRIM passthrough works, though zeroed erase blocks do reveal something about the encrypted partition.  You have to decide how valuable your information is.

 

yip, and that's a problem i just plain dont see a way to fix. I don't think it ever will be. You can't present a disk full of random data when a full disk is counter to the functionality of an SSD. 

i just cant justify it. I need airtight. I just can't justify leaving even the slightest opening for the sake of what is, granted, a substantial performance benefit, when on the whole my machines already work worlds faster than my brain can manage. 

it's really really really tempting. And frustrating. A speedy enough disk and i could keep a Windows VM that i need for work running full time. Just can't do it. Too paranoid I guess.

----------

## mv

 *cach0rr0 wrote:*   

> yip, and that's a problem i just plain dont see a way to fix.

 

Well, in theory the kernel could postpone in a random manner to free some blocks. However, I guess it does not appear important enough to implement it. I cannot imagine that the information about free blocks is so valuable that you can draw any serious conclusions from it: Even hypothetical, I do not see any such examplle in the moment.

----------

## Hypnos

You need to do a cost/benefit analysis:

How much would it cost to compromise your data with and without TRIM enabled, and how do these compare to the value of your data?

How much is the speed of an SSD worth to you compared to the cost of using an SSD, with and without TRIM?

----------

## Ion Silverbolt

I compile all my programs in a chroot from my desktop and install the binaries onto my netbooks SSD. The netbook has Gentoo on it yet never has compiled anything.

----------

## d2_racing

I have an Intel SSD 520 series and I use a big tmpfs 12 gigs for /var/tmp/portage and I use btrfs too.

```

/dev/sda3      /boot            ext2       noauto,noatime,defaults                     1 2

/dev/sda1      /boot/efi        vfat       noauto,defaults                             0 0

/dev/sda4      /                btrfs      defaults,noatime,ssd,discard,compress=lzo,subvol=@racine 0 1

tmpfs          /var/tmp/portage tmpfs      size=12G                                    0 0

none           /dev/shm         tmpfs      nodev,nosuid,noexec                         0 0

/dev/sdb2      /mnt/win_c       ntfs       defaults,ro,user,nls=iso8859-1,nls=utf8,umask=0 0 0

/dev/sdc2      /mnt/win_d       ntfs       defaults,ro,user,nls=iso8859-1,nls=utf8,umask=0 0 0

```

----------

## cach0rr0

 *Hypnos wrote:*   

> You need to do a cost/benefit analysis:
> 
> How much would it cost to compromise your data with and without TRIM enabled, and how do these compare to the value of your data?
> 
> How much is the speed of an SSD worth to you compared to the cost of using an SSD, with and without TRIM?

 

I'm in a fortunate position where I can have craploads of backups, all over the place (and all of them encrypted as well)

So my chances of losing data - at least the important stuff, I don't include my stash of funny animated gifs in my backups - are low short of a catastrophic global event. 

Data compromise is more likely for me at the borders, where my "4th Amendment" rights are suspended. I don't have anything that *should* interest folks in my government, but that's the old, "if you have nothing to hide..." - right, so, dear government, it's my damn data, you can sod right off thinking you're entitled to it. The worry is of course that I get my HDD cloned, and some government leech sitting in an air conditioned underground bunker gets to take his time trying various attacks at his leisure - mathematically, it should take many lifetimes to get at my data, so I don't want anything to make it easier on 'em. 

Getting at my unencrypted disk means saved passwords, saved crypto keys for other things, that frankly the government has no business seeing. It's mine. Not the property of anyone else. 

So yeah, I've been holding off on pulling the trigger on an SSD for i think the past 2 or 3 years thanks to that. Just I convince myself "well, the risk is so low", I always come back to "nah, cant risk it"

----------

## Hypnos

So I guess the conclusion is that the security of your data is priceless to you.

For me, I just want to prevent identity theft.  If I some NSA spook wants to read my diary entries, fine by me.

I may reevaluate if I ever become important.

----------

## cach0rr0

 *Hypnos wrote:*   

> So I guess the conclusion is that the security of your data is priceless to you.
> 
> For me, I just want to prevent identity theft.  If I some NSA spook wants to read my diary entries, fine by me.
> 
> I may reevaluate if I ever become important.

 

purely a matter of principle. I am completely and totally unimportant and uninteresting to a government. 

but my data, the things that are in my brain - this is our last bastion, our last frontier, of things that the government can't touch or meddle in. 

If they come with actual guns blazing to take my property, to arrest me, kill me, whatever else, I can offer little resistance. 

But if they come for my data, they have no better chance of "winning" than I do - in fact, it's a rare case where I have an advantage. 

so if they want pictures of my cat and my guns, or if they want to sift through my porn stash - the bastards are gonna have to work for it.

----------

## dmpogo

 *cach0rr0 wrote:*   

>  *LoTeK wrote:*   but I guess 4G is too small 
> 
> for most things, no
> 
> but for things like Thunderbird, Firefox, libreoffice/openoffice, Chromium, yes, that will be too small.

 

I was happily compiling everything but those guys in tmpfs with 2GB on my laptop.   Those four monsters I use in bin version anyway.

----------

## ppurka

I compile stuff in tmpfs too (using 2G out of 4G RAM), except for firefox/chromium, oo/libreoo and thunderbird. I use the -bin versions of them. It's no use trying to compile them. I think a big benefit of compiling is slightly faster startup, but it is not worth spending hours compiling such a big package when binary versions are available.

I have been trying out using a zram mounted /tmp, and have allocated 500M to it. I have made my browser cache go to the /tmp and have never seen the usage go above 50M.

----------

## DaggyStyle

I have a small question about /var/tmp/portage on tmpfs, does the behavior is similar to /var/tmp/portage on disk when it comes to compilation failures? e.g. logs are still available?

also, will 6gb be enough? I thinking of moving  /var/tmp/portage to ram but as my wife uses win7 with 10gb of ram, I don't want to run out of ram (got 16gb of ram and 16 gb of swap).

Thanks.

----------

## Hypnos

 *DaggyStyle wrote:*   

> I have a small question about /var/tmp/portage on tmpfs, does the behavior is similar to /var/tmp/portage on disk when it comes to compilation failures? e.g. logs are still available?

 

The behavior should be identical until the machine is powered off.  I don't see why it would be different, since a tmpfs looks the same to Portage as any conventional filesystem.

 *Quote:*   

> also, will 6gb be enough? I thinking of moving  /var/tmp/portage to ram but as my wife uses win7 with 10gb of ram, I don't want to run out of ram (got 16gb of ram and 16 gb of swap).

 

You mean your wife runs Win7 in a VM?  It depends how large of a package you want to compile.  Chromium, Firefox, Thunderbird and open/libreoffice take over 3GB; I don't know of another package that takes even 1GB.

----------

## eccerr0r

Yes it's very odd that most apps don't get anywhere close to filling tmpfs.  The only application that fails to build on my 2GB (1GB Tmpfs) system is firefox (since Libreoffice I use binaries).  I suspect gcc and glibc are up there too but I don't ever recalling them fail to build.  I typically hook up an external USB disk to build firefox on my eeepc that has 2GB RAM.

So far, as of right now, only my 8GB machine can build firefox completely in RAM, thus the 180G SSD520 disk gets write savings.  The 128G Crucial is in a 4G machine and it however is not enough to build firefox.  But I just disable tmpfs and let it use as much ssd to build firefox.

This leads to another issue, I sometimes wish Gentoo didn't build into a temp area then copy to root...that's a lot of extra writes... but I suppose there's no way to get around this and maintain ability to back out of changes...

----------

## DaggyStyle

 *Hypnos wrote:*   

>  *DaggyStyle wrote:*   I have a small question about /var/tmp/portage on tmpfs, does the behavior is similar to /var/tmp/portage on disk when it comes to compilation failures? e.g. logs are still available? 
> 
> The behavior should be identical until the machine is powered off.  I don't see why it would be different, since a tmpfs looks the same to Portage as any conventional filesystem.
> 
>  *Quote:*   also, will 6gb be enough? I thinking of moving  /var/tmp/portage to ram but as my wife uses win7 with 10gb of ram, I don't want to run out of ram (got 16gb of ram and 16 gb of swap). 
> ...

 

yes, my wife runs Win7 in a VM.

if I'm not mistaken, libreoffice checks for minimal amount of ram, not sure how much.

----------

## ppurka

 *Hypnos wrote:*   

> You mean your wife runs Win7 in a VM?  It depends how large of a package you want to compile.  Chromium, Firefox, Thunderbird and open/libreoffice take over 3GB; I don't know of another package that takes even 1GB.

 gcc will easily take close to 2G, and gcc with fortran enabled will take more than 2G.

----------

## logical_guy

Looking at my filesystem, I have /tmp in tmpfs.  Also, /usr/tmp is symlinked to /var/tmp, which is again symlinked to /tmp/.

Is this normal or did I do something I shouldn't have.. lol.

Guess that means /var/tmp, including /var/tmp/portage is already in RAM.

----------

## Hypnos

ppurka,

I'll go with your figures since I have not emerged gcc recently.

***

logical_guy,

I think that's problematic, as the "portage" subdir will disappear every time you reboot.  I would put /var/tmp/portage on a separate tmpfs.

----------

## mv

 *logical_guy wrote:*   

> /usr/tmp is symlinked to /var/tmp, which is again symlinked to /tmp/.

 

The first link is fine, the second does not conform to FHS: /var/tmp is supposed to live over reboots while /tmp is supposed to be cleaned on every boot.

----------

## logical_guy

 *mv wrote:*   

>  *logical_guy wrote:*   /usr/tmp is symlinked to /var/tmp, which is again symlinked to /tmp/. 
> 
> The first link is fine, the second does not conform to FHS: /var/tmp is supposed to live over reboots while /tmp is supposed to be cleaned on every boot.

 

Yeah, thanks for that.  I've corrected it now.  I have /var/tmp/portage in tmpfs now, should I throw /tmp in as well?

----------

