Qrux wrote:
> On May 23, 2012, at 4:00 PM, Bruce Dubbs wrote:
>
>> I decided to explore using an ssd drive. I purchased a 40G Intel SSD
>> and so far it works well with SVN-20120514.
>>
>> I created a GPT partition table with a 10G partition using parted and
>> formatted as ext4.
>>
>> The performance seems to be good. htparm gives me about 230 GB/s which
>> is more than twice as fast as my usual drives that give about 105 GB/s.
>>
>> My question is how to best use the new drive in BLFS. I thought of /opt
>> and /usr. I don't think /home would be very good and of course I could
>> try to mount it as /mnt/lfs and use it as /.
>>
>> What would you try first?
>
> I would definitely avoid using it to build; that's probably what you
> meant when you said to avoid /home. It's faster (esp. for testing)
> to use an in-memory filesystem if you find that your FS is a
> bottleneck (which I haven't found).
>
> Booting is awesome with SSDs. So is having /bin and /usr on them.
> Any setting where you spend oodles of time seeking is where you'll
> see the most benefit with SSDs. Yes, sustained reads are faster,
> (though hdparm is pretty bad at measuring that; try using something
> more purpose-built like iozone or bonnie++), but it's all about the
> IOPS with SSDs.
>
> I've used an SSD to store images of my host OS and the LFS downloads.
> My host OS install blazes when I configure it to install from a
> "hard drive partition" (which sits on the SSD) rather than from the CD.
>
> I would also make sure to use noatime and make sure that I don't put
> /var on it. Maybe relatime is okay, but I'd rather have data on the
> SSD, and avoid atime writes at all. Obviously, don't put swap on it.
Thanks for the responses, Baho, Ken, and Qrux. I did mount with
noatime,discard,data=writeback and I also set hdparm -W1. I think the
important directories to have on a fast disk would be /bin, /lib, and
/usr/{bin,lib}. I'd think that any other files that may be on /etc or
/usr/share would not show much difference.
At this point, I would not want to do extensive builds on the new drive
as they do a lot of writing, but I probably will test a couple to see if
it makes much difference.
As a quick initial test, I built rsync on the new drive and the build
time, including tests, was not significantly different than from the
standard disk (37.6 seconds vs 40.1 seconds). The ssd build was
actually slightly slower.
For Ken, the reason I use /opt is primarily as an adjunct to
/usr/{bin,lib}. It can segregate a package and if I want to build a
large package, say Qt, I can put it there and then upgrade it without
worrying if there are version conflicts. When I was working, I used Qt
a lot and it was quite convenient, especially when transitioning from
Qt3 to Qt4. On my latest system, I have icedtea, xorg, and ant on /opt.
I use it as a crude package manager so that new packages can be
installed and tested with the capability of easily backing up to older
versions of a package if desired.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
