gmane.linux.lfs.beyond.devel

Re: BLFS Status

Ken Moffat — 2012-05-25T23:03:58

 I too have the non-versioned directories from xorg protocol headers
and libs (didn't check to see which).  No, I've never installed fop.
I build the protocols, and probably the libs, in the same way and
order as in BLFS.

ĸen

Re: BLFS Status

Bruce Dubbs — 2012-05-25T20:59:25


I haven't seen those at all.  The note on the page says:

"There is a reciprocal dependency with fop-1.0. If you wish to build the 
documentation, you'll need to re-install the Protocol Headers after the 
installation is complete and fop-1.0 has been installed."

Did you do that?


I haven't gotten to those on my new build, but my old system has 
glibmm-2.4, libcairomm-1.0, and gtkmm-2.4.

   -- Bruce

Re: BLFS Status

Armin K. — 2012-05-25T20:09:44

Not sure, but mostly xorg protocol headers and xorg libraries install 
docs into non-versioned docdir here. I remove those directories. Also, 
the *mm packages also install into sort of non-versioned directory. (ie 
glibmm-2.4 with libglibmm-2.4.so), gnome-js-common ... Could it be that 
Xorg packages install docs because I have xmlto since it shows detection 
of it at configure time?

Re: BLFS Status

Bruce Dubbs — 2012-05-25T19:36:31


I'm not sure how that started, but it's to identify the version of the 
package.  It one version has doc1 and doc2, a second version may drop 
doc1 and add doc3.  It's a crude form of version control, but one we've 
been doing a long time.

Personally, if I did rm -r /usr/share/doc, I don't think I'd miss it 
very often.  Looking at my older system, I have some docs that go back 
to vim-6.4, hal-0.5.4, imlib2-1.2.2, xmms-1.2.10, etc.

The whole directory is 369M, so it uses some space, but then again, it's 
only 3% of my 10G directory.  On my recent system it's 126M.

I don't see a lot of non-versioned docs.  Only check, lame, pkg-config, 
speex, sudo, and udev-config.  It would be easier to change those than 
to remove the version everywhere else.

It's a bit more of a mixtue on /usr/share.

   -- Bruce

Re: BLFS Status

Armin K. — 2012-05-25T17:55:59

Wow, I did not even know that BLFS has that many packages. Also, I'd 
like to use this to ask for something.

In LFS and BLFS we use package-package-version for docdir, eg 
/usr/share/doc/attr-2.4.46. Why? I mean, it is somehow stupid if you ask 
me. If you keep your system arround for some time, and upgrade such 
packages, you will have dozen of versioned directories in there. But 
that's not all. There are lot of packages that just install their 
documentation in non-versioned directory, especially Xorg stuff. So in 
the end, we have half of packages with versioned docdir and half with 
non-versioned. So, which one to keep? Which one would suit us better?

BLFS Status

Bruce Dubbs — 2012-05-25T17:28:54

As of right now, we have

344 packages marked with lfs70_checked
274 packages marked with lfs71_checked
   0 packages marked with lfs6?_checked

There is one package not marked that I know of, icedtea, and that is 
being worked.

There are 15 open tickets.  Two are new apps, 11 are upgrades to 
existing packages (including icedtea).  Two tickets do not involve 
package upgrades.

   -- Bruce

Re: ssd drives

Bruce Dubbs — 2012-05-25T03:01:04


Mine is Intel(R) Core(TM)2 Duo CPU E8400  < at > 3.00GHz
I have 3G of RAM.


It does say that in Section 2.4 for /mnt/lfs but I don't remember why.

I went back and searched the archives and see something about the glibc 
tests from 2003.


I agree.


Depends too on disk caching.


No, I think I'm about spent on this issue for now.

   -- Bruce

Re: ssd drives

Qrux — 2012-05-25T02:14:48

On May 24, 2012, at 6:19 PM, Bruce Dubbs wrote:


Interesting.  And unlike my experience...I barely observed more than
a 10 minute speedup over an entire automated build (using LFS, and then
building enough of BLFS to support Xen)--which took about 3 to 4 hours.

On my SSD test machine, my processor & memory weren't great.  i5-2400
with pretty tame memory.  Are yours much faster?  I wonder if my stuff
was system made the build CPU-bound...

Where does LFS stand now with respect to building with noatime?
I thought I read in 7.0 that that was bad news (I remember something
being atime-sensitive, and breaking; maybe it was the glibc or
coreutils test suite...)


I do agree that journaling is a whole other beast; i.e., if
we treat /usr and /bin as read-only (as a simplifying assumption)
then journaling should be entirely unnecessary, once they are created.

But...I think you may be missing the benefit of noatime.  The
purpose is to prevent write I/O when you just read files, by having
to update the inode on an

Re: ssd drives

Bruce Dubbs — 2012-05-25T01:19:43


Not exactly.  GRUB is on sda and so is /boot.  GRUB reads the linux 
kernel from /boot and then the kernel initializes and sets up sdc1 as 
the root fs.


I'm not sure what you mean by login here.  The process is to power on 
(or reboot), have the BIOS do some initialization, and then run grub. 
The BIOS initialization (where we have no control) takes 2-3 seconds and 
then the GUUB prompt shows almost immediately after that.  From the GRUB 
selection to the linux login prompt takes a lot more than one second. 
Just running '/sbin/udevadm trigger --action=add --type=subsystems' 
takes considerably more than one second.


That's an interesting discussion.


I created a new ext4 partition and mounted it noatime.  My rsync build 
time was 20.3 seconds -- basically the same as ext3 with default mount 
options.

For things like /bin and /usr, I wouldn't be particularly concerned 
about atime and journaling since there is little or no writing (except 
when doing the install part of a build).

   -- Bruce

Re: ssd drives

Qrux — 2012-05-24T23:26:08

On May 24, 2012, at 3:38 PM, Bruce Dubbs wrote:


Are you booting from sdc (i.e., BIOS is booting from sdc)?

IDK what the rest of your setup is, but IIRC, I can get to login
(after BIOS POST, etc) in about a second.


Interesting data, but it might be a bit misleading to attribute all
the speedups to the SSD:

1) /tmp is ext3
2) /tmp is mounted with kernel defaults (relatime?)
3) / is mounted with data=writeback

1. Ext3 is probably far worse than ext4 for CMMI tasks.  Ext4 is
faster on file creation, and if it's used without barriers is going
to be much faster on writes.  Obviously the tradeoff is there is
filesystem safety.

2. Mounted with defaults, I'd guess that ext3 is probably using
relatime.  This is better than with atime enabled, but probably far
worse than noatime.  IIRC, relatime still writes atime, but just less
frequently.  It's still not as good as noatime.  Here's a casual
write-up (with references to the epic war on LKML):

http://tinyurl.com/2exlv7u

3. That same article quotes Torval

Re: ssd drives

Bruce Dubbs — 2012-05-24T22:38:24

I just want to share some things I've found out about ssd drives.

I installed the ssd drive as /dev/sdc and created a gpt partition table 
with parted.  The fist partition, /dev/sdc1, is about 11G.

I created a ext4 filesystem and mounted as /mnt/ssd.

Next I created the root directories: bin, boot, dev, etc, home,
lib, media, mnt, opt, proc, root, sbin, srv, sys, tmp, usr, var.

Then a symbolic link: lib64 -> lib

[/mnt/ssd] $ cp -a /etc/* etc
I did the same for bin, sbin, lib, usr, root

I updated /boot/grub/grub.cfg and found I needed some parameters on the 
boot line:

linux   /vmlinuz-3.3.6-lfs-20120515 root=/dev/sdc1 rootfstype=ext4 ro 
raid=noautodetect rootflags=data=writeback

The new items were rootfstype=ext4 and rootflags=data=writeback.

I did not initially create /run because I thought it was created in the 
first bootscript, but found that it couldn't be created because the 
filesystem is mounted as read only.  I'll need to remove that line in 
the boot script because it doesn't do anything.

Re: ssd drives

Bruce Dubbs — 2012-05-24T15:38:17

Of course there will be some variations, even on the same machine, due 
to other activities, caching, etc.  I'd say timings should, in general, 
be repeatable withing 5%, but could reach 10%.  More than that would 
mean something is happening like getting into swap.

   -- Bruce

Re: icedtea notes

Bruce Dubbs — 2012-05-24T15:33:31



What tools wolud that be?  I do not have gdb installed.  I did have all 
the 1.9.7 listed dependencies:  alsa-lib-1.0.25, Cups-1.5.0, 
gtk+-2.24.10, Xorg Libraries, xulrunner, apache-ant-1.8.3, UnZip-6.0, 
which-2.20, and Zip-3.0.  cpio is required too.

BTW, I think apache-ant is required, not optional.  At least I didn't 
see a way around it.  There is a circular dependency there.  My order was:

Tue May 22 11:21:21 2012 /usr/src/junit/junit4.10.zip
Tue May 22 11:24:56 2012 /usr/src/apache-ant/apache-ant-1.8.3-src.tar.bz2
Tue May 22 11:33:17 2012 /usr/src/cpio/cpio-2.11.tar.bz2
Tue May 22 11:38:15 2012 /usr/src/giflib/giflib-4.1.6.tar.bz2
Tue May 22 11:45:30 2012 /usr/src/cups/cups-1.5.0-source.tar.bz2
Tue May 22 20:09:25 2012 /usr/src/nspr/nspr-4.9.tar.gz
Tue May 22 20:17:32 2012 /usr/src/nss/nss-3.13.4.tar.gz
Wed May 23 02:13:58 2012 /usr/src/icedtea/icedtea-2.1.tar.gz

Looking at configure, there seem to be several dependencies we don't 
mention:  gcj, openssl, zlib, jpeg, gif, lcms, gtk, gio, foncon

Re: ssd drives

Ken Moffat — 2012-05-24T13:39:27

 Umm, how *repeatable* they are.

ĸen

Re: icedtea notes

DJ Lucas — 2012-05-24T12:41:18

Hmm...JDI is the debug interface. I don't have an immediate explanation 
for that. Do you have traditional debugging tools available in the 
environment? They should not have an effect, but at the time I tested, I 
did not have them available.


This could be due to the window manager. I always sit and watch it 
through the tests. There were a couple where my login window was to 
blame when it was trying to iconify and restore windows. Also, root or 
unprivileged user? My results were obtained as an unprivileged user, 
using TWM on a fairly minimal system (just enough to meet required and 
recommended deps).

On a side note, 2.2 is scheduled for release next Wednesday (5/30). I 
don't anticipate any changes in the options or dependencies. 2.2 will 
basically be the same as the Oracle 7u4 with some of the security 
updates that are slotted for 7u5, along with the typical build fixes for 
newer system software and the closed parts of the software replaced by 
free software (easily arguable as _better_ replacem

Re: ssd drives

Ken Moffat — 2012-05-24T02:42:31

 Sure, I understand that.  But I imagine, perhaps wrongly, that
desktop environments will work better if they are on the fast disk.
So, using the SSD for / but with xorg and kde or qt in /opt on a
conventional drive would probably be slow to load.

 The other interesting feature about timings is how measurable they
are.  On my own machines there will be some cron jobs running from
time to time (disk checks with smartmontools - maybe not relevant
to the SSD but can be useful for conventional disks, log rotation,
backups, etc), plus whatever loadset is currently active [ think of
firefox as a memory hog ], plus any data in caches unless you drop
them.  For small packages, I expect to see variations of a few
seconds in build times.

 Anyway, enjoy it!

ĸen

Re: ssd drives

Bruce Dubbs — 2012-05-24T01:46:46

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

Re: ssd drives

Qrux — 2012-05-24T00:16:05

On May 23, 2012, at 4:00 PM, Bruce Dubbs wrote:


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

Re: ssd drives

Ken Moffat — 2012-05-24T00:00:50

 If it was one of the cheap drives where the problems might be
slowness once it has to free up a lot of deleted space, and perhaps
a limit on how many times it can be updated before it fails, I'd be
inclined to try is as a r/o / but loaded from a real disk once the
system has all been built.  But it's NOT one of those, and I believe
Linus uses one as a normal disk.

 So, where will you benefit from the speed ?  In the old days /tmp
could have been useful, but now /tmp is RAM backed.  For me,
untarring and rm -rf to remove built packages is one of the big
delays.  So, *I* might be tempted to use it at /scratch (for me
that's where I put the "spare" space from my 500GB system disks - it
isn't backed up, unlike my /home, and it's where I build kernels, do
test builds of packages, and also where I will be doing media work
(transcoding etc).

 I recall that your partition usage is very different from mine, but
I think you need to look at the purpose of your partitions, not at
where you happen to mount them.  For

Re: ssd drives

Baho Utot — 2012-05-23T23:52:24

I have been using an SSD and a reg HD for about 1 month now

here is how I setup the file system.

/etc/fstab
#    These part are on the SSD
/dev/sdb1 /boot ext4 defaults,noatime,discard 0 1
/dev/sdb2 / ext4 defaults,noatime,discard 0 1

#    These part are on the HD
/dev/mapper/lvm-home /home ext4 defaults,noatime 0 1
/dev/mapper/lvm-media /media ext4 defaults,noatime 0 1
/dev/mapper/lvm-swap swap swap defaults 0 0
/dev/mapper/lvm-var /var ext4 defaults,noatime 0 1

You should set discard on all the part that are on the SSD to enable TRIM.

ssd drives

Bruce Dubbs — 2012-05-23T23:00:14

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?

   -- Bruce