do gentoo/compiling harm ssd's?

Message

LoTeK · Post by **LoTeK** » Sat Nov 17, 2012 9:11 pm

I've just read about why some people change from gentoo to arch (for those who understand german:
http://www.hardwareluxx.de/community/f2 ... 83591.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"

Post by **NeddySeagoon** » Sat Nov 17, 2012 9:34 pm

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 · Post by **LoTeK** » Sat Nov 17, 2012 9:52 pm

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 · Post by **alkan** » Sat Nov 17, 2012 10:11 pm

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.

Post by **NeddySeagoon** » Sat Nov 17, 2012 10:12 pm

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 · Post by **logical_guy** » Sat Nov 17, 2012 10:31 pm

can you post your fstab, neddy?

LoTeK · Post by **LoTeK** » Sat Nov 17, 2012 10:39 pm

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.

Hypnos · Post by **Hypnos** » Sat Nov 17, 2012 11:02 pm

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 · Post by **cach0rr0** » Sat Nov 17, 2012 11:04 pm

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.

Post by **NeddySeagoon** » Sat Nov 17, 2012 11:22 pm

logical_guy,

Are you sure ?

Code: Select all

# <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 · Post by **LoTeK** » Sun Nov 18, 2012 1:06 am

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 · Post by **lexming** » Sun Nov 18, 2012 3:06 am

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:

Code: Select all

 $ cat /etc/portage/package.env 
app-office/libreoffice nozram.conf
www-client/firefox nozram.conf

Code: Select all

 $ cat /etc/portage/env/nozram.conf 
PORTAGE_TMPDIR="/var/bigtmp"

eccerr0r · Post by **eccerr0r** » Tue Nov 20, 2012 6:02 pm

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 · Post by **cach0rr0** » Tue Nov 20, 2012 10:50 pm

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.

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

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 · Post by **Hypnos** » Tue Nov 20, 2012 11:11 pm

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 · Post by **cach0rr0** » Wed Nov 21, 2012 12:12 am

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 · Post by mv » Wed Nov 21, 2012 12:26 am

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 · Post by **Hypnos** » Wed Nov 21, 2012 1:02 am

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 · Post by **Ion Silverbolt** » Wed Nov 21, 2012 1:51 am

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 · Post by **d2_racing** » Wed Nov 21, 2012 4:41 am

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

Code: Select all

/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 · Post by **cach0rr0** » Wed Nov 21, 2012 5:51 am

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 · Post by **Hypnos** » Wed Nov 21, 2012 5:58 am

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 · Post by **cach0rr0** » Wed Nov 21, 2012 6:10 am

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 · Post by **dmpogo** » Wed Nov 21, 2012 6:54 am

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 · Post by **ppurka** » Wed Nov 21, 2012 8:06 am

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.