phaqphaq

It’s been almost a year now since phunsites was relaunched after a rather long time of absence.

I remember writing my first post, which expressed my doubts that I would ever find enough time to create a unique web design.

However, after reflecting about phunsites and the achievements made so far, I finally decided to climb the mountain.

A great deal of work has already been completed, including creating the new design, adding link redirects, changing article references and micj more.

But there is still plenty of work to do, which includes re-implementing the photo gallery and the media archive (changeing their original web design will be driving me crazy for sure…) and fixing some minor glitches here and there.

As you’ve propably noticed, there is also a drastic change in the site structure itself. While there was just “Phlog” (Phunsites Blog) in the past, the site will be divided into several subsites in the future.

“Phlog” was already replaced the “phaq” (Phunsites FAQ), which will however cover the same tech topics as before.
With “phersonal” (Phunsites Personal) a new sidekick covering primarily personal topics has been added to the site.

And for the inpatient ones who can’t wait for new topics on Phlog/phaq: Yes, there are some new articles underway, including the FreeBSD software RAID benchmarks promised a few days ago.

It’s time. Let’s farewell “rampart” and welcome the new ph! style. Enjoy!

In case you ever happen to be listed on a DNS blacklist you’ll propably find it useful checking for the actual DNS reply.
The point is that many popular blacklists usually provide information and database checks on their websites, however the latter one very often do not reflect current entries withint the blacklist.

So, the way to go is either using ‘host’, ‘dig’ or ‘nslookup’. Requested addresses must be specified equally as if you were actually searching for a reverse entry (PTR).

In the example given, the IP address “192.168.0.1″ (reversed 1.0.168.192) is assumed, while ‘ns.of.choice’ is a synonym for your local nameserver.

So a query for ‘dig’ might look like this (output stripped a little):

#dig 1.0.168.192.blacklist.domain.tld @ns.of.choice ANY
;; QUESTION SECTION:
;1.0.168.192.blacklist.domain.tld. IN ANY

;; ANSWER SECTION:
1.0.168.192.blacklist.domain.tld. 3600 IN A 127.0.0.6
1.0.168.192.blacklist.domain.tld. 3600 IN TXT “sample for typical rbl message”

The same query for the ‘host’ command:

#host -t any 1.0.168.192.blacklist.domain.tld ns.of.choice
Using domain server:
Name: ns.of.choice
Address: 192.168.1.1#53
Aliases:

1.0.168.192.blacklist.domain.tld has address 127.0.0.6
1.0.168.192.blacklist.domain.tld descriptive text “sample for a typical rbl message”
And the same again using ‘nslookup’:

#nslookup -class=any 1.0.168.192.blacklist.domain.tld ns.of.choice
Server: ns.of.choice
Address: 192.168.1.1#53

Name: 1.0.168.192.blacklist.domain.tld
Address: 127.0.0.6
1.0.168.192.blacklist.domain.tld text = “sample for typical rbl message”

You may also choose to query any authoritative nameserver of the blacklist in particular (refer to authority section or the SOA records respectively), since querying your local name-server may be not be accurate due to TTL intervals.

CompleteWhois also provides a conventient interface for searching multiple RBL’s at once.

In case you forget the password for an Areca ARC-1210 controller, the master password might be your friend

Here it is:

MNO974315743924

I’m not sure if I’m actually allowed to publish this here. However, I did never sign a NDA get it, so I think it’s ok.

One might asume building a port from source should be fast and straight forward.
Not in this case, however…

# cd /usr/ports/devel/p5-File-Tail
# make clean build
===> Cleaning for perl-5.8.8
===> Cleaning for p5-File-Tail-0.99.3
===> Vulnerability check disabled, database not found
===> Extracting for p5-File-Tail-0.99.3
=> MD5 Checksum OK for File-Tail-0.99.3.tar.gz.
=> SHA256 Checksum OK for File-Tail-0.99.3.tar.gz.
===> p5-File-Tail-0.99.3 depends on file: /usr/local/bin/perl5.8.8 – found
===> Patching for p5-File-Tail-0.99.3
===> p5-File-Tail-0.99.3 depends on file: /usr/local/bin/perl5.8.8 – found
===> Applying FreeBSD patches for p5-File-Tail-0.99.3
===> p5-File-Tail-0.99.3 depends on file: /usr/local/bin/perl5.8.8 – found
===> Configuring for p5-File-Tail-0.99.3

File::Tail will be installed without debugging information.
This information isn’t usefull unless you intend to tinker
with the code. To install with debugging enabled, use:
perl Makefile.PL LOGIT
Checking if your kit is complete…
Looks good
Writing Makefile for Mail
==> Your Makefile has been rebuilt. <==
==> Please rerun the make command. <==
false
*** Error code 1

Stop in /usr/ports/devel/p5-File-Tail/work/File-Tail-0.99.3

Usually, this particular error happens only if local time/date is not set correctly.

Good, so show me the date, please:

# date
Wed Jan 10 11:49:18 CET 2007

But what is this? Date and time seems right.
Maybe something wrong with the files within the port directory?

# cd /usr/src/devel/p5-File-Tail
# make clean && make extract
# find ./work/File-Tail-0.99.3/ -type f -exec ls -l {} \;
-rw-r--r-- 1 root wheel 452 Sep 14 2005 ./META.yml
-rw-r--r-- 1 root wheel 1931 Dec 18 1998 ./t/20tail.t
-rw-r--r-- 1 root wheel 912 Sep 14 2005 ./t/30name_change.t
-rw-r--r-- 1 root wheel 1653 Dec 18 1998 ./t/10open.t
-rwxr-xr-x 1 root wheel 1101 Feb 2 1999 ./select_demo
-rw-r--r-- 1 root wheel 27994 Jan 10 11:47 ./Tail.pm.debug
-rw-r--r-- 1 root wheel 4812 Sep 14 2005 ./Changes
-rwxr-xr-x 1 root wheel 1381 Nov 3 1999 ./logwatch
-rw-r--r-- 1 root wheel 198 Sep 14 2005 ./MANIFEST
-rw-r--r-- 1 root wheel 25311 Jan 10 11:47 ./Tail.pm
-rw-r--r-- 1 root wheel 2471 Oct 17 2000 ./Makefile.PL
-rw-r--r-- 1 root wheel 2143 Feb 2 1999 ./README
-rw-r--r-- 1 root wheel 27991 Sep 14 2005 ./Tail.pm.debug.orig
-rw-r--r-- 1 root wheel 23027 Jan 10 11:47 ./Makefile
-rw-r--r-- 1 root wheel 0 Jan 10 11:47 ./blib/lib/File/.exists
-r--r--r-- 1 root wheel 25311 Feb 9 11:47 ./blib/lib/File/Tail.pm
-rw-r--r-- 1 root wheel 0 Jan 10 11:47 ./blib/lib/auto/File/Tail/.exists
-rw-r--r-- 1 root wheel 0 Jan 10 11:47 ./blib/arch/.exists
-rw-r--r-- 1 root wheel 0 Jan 10 11:47 ./blib/arch/auto/File/Tail/.exists
-rw-r--r-- 1 root wheel 0 Jan 10 11:47 ./blib/bin/.exists
-rw-r--r-- 1 root wheel 0 Jan 10 11:47 ./blib/script/.exists
-rw-r--r-- 1 root wheel 0 Jan 10 11:47 ./blib/man1/.exists
-rw-r--r-- 1 root wheel 0 Jan 10 11:47 ./blib/man3/.exists
-rw-r--r-- 1 root wheel 14740 Jan 10 11:47 ./blib/man3/File::Tail.3
-rw-r--r-- 1 root wheel 0 Jan 10 11:47 ./pm_to_blib

Well, nothing bad here either.
However, it *has* to be something about the date.

Maybe, there is some issue with perl libs, MakeMaker in
particular, then?

Let's see:

# find /usr/local/lib/perl5/ -name "*MakeMaker*" -exec ls -l {} \;
-r--r--r-- 1 root wheel 78826 Feb 9 08:48 /usr/local/lib/perl5/5.8.8/ExtUtils/MakeMaker.pm
total 20
-r--r--r-- 1 root wheel 565 Feb 9 08:48 Config.pm
-r--r--r-- 1 root wheel 7605 Feb 9 08:48 FAQ.pod
-r--r--r-- 1 root wheel 4387 Feb 9 08:48 Tutorial.pod
-r--r--r-- 1 root wheel 769 Feb 9 08:48 bytes.pm
-r--r--r-- 1 root wheel 707 Feb 9 08:48 vmsish.pm
-rw-r--r-- 1 root wheel 19874 Feb 9 08:49 /usr/local/lib/perl5/5.8.8/perl/man/man3/ExtUtils::MakeMaker.3.gz
-rw-r--r-- 1 root wheel 1866 Feb 9 08:49 /usr/local/lib/perl5/5.8.8/perl/man/man3/ExtUtils::MakeMaker::Config.3.gz
-rw-r--r-- 1 root wheel 1983 Feb 9 08:49 /usr/local/lib/perl5/5.8.8/perl/man/man3/ExtUtils::MakeMaker::bytes.3.gz
-rw-r--r-- 1 root wheel 3631 Feb 9 08:49 /usr/local/lib/perl5/5.8.8/perl/man/man3/ExtUtils::MakeMaker::Tutorial.3.gz
-rw-r--r-- 1 root wheel 5239 Feb 9 08:49 /usr/local/lib/perl5/5.8.8/perl/man/man3/ExtUtils::MakeMaker::FAQ.3.gz
-rw-r--r-- 1 root wheel 1937 Feb 9 08:49 /usr/local/lib/perl5/5.8.8/perl/man/man3/ExtUtils::MakeMaker::vmsish.3.gz
-r--r--r-- 1 root wheel 3905 Feb 9 08:49 /usr/local/lib/perl5/5.8.8/BSDPAN/ExtUtils/MakeMaker.pm

There it is! You see?
Obviously the was a timestep forward one the system clock sometimes in the past, so files created then actually got a timestamp in the future.

So let's fix this and try rebuilding the port.

# find /usr/local/lib/perl5/ -name "*MakeMaker*" -exec touch {} \;
# cd /usr/ports/devel/p5-File-Tail
# make clean build
===> Cleaning for perl-5.8.8
===> Cleaning for p5-File-Tail-0.99.3
===> Vulnerability check disabled, database not found
===> Extracting for p5-File-Tail-0.99.3
=> MD5 Checksum OK for File-Tail-0.99.3.tar.gz.
=> SHA256 Checksum OK for File-Tail-0.99.3.tar.gz.
===> p5-File-Tail-0.99.3 depends on file: /usr/local/bin/perl5.8.8 – found
===> Patching for p5-File-Tail-0.99.3
===> p5-File-Tail-0.99.3 depends on file: /usr/local/bin/perl5.8.8 – found
===> Applying FreeBSD patches for p5-File-Tail-0.99.3
===> p5-File-Tail-0.99.3 depends on file: /usr/local/bin/perl5.8.8 – found
===> Configuring for p5-File-Tail-0.99.3

File::Tail will be installed without debugging information.
This information isn’t usefull unless you intend to tinker
with the code. To install with debugging enabled, use:
perl Makefile.PL LOGIT
Checking if your kit is complete…
Looks good
Writing Makefile for File::Tail
===> Building for p5-File-Tail-0.99.3
cp Tail.pm blib/lib/File/Tail.pm
Manifying blib/man3/File::Tail.3

So we learn an important lesson from this: Perl’s MakeMaker does not only fail the build process if the system clock is set incorrectly.
It does so also if the timestamps on any source files and MakeMaker’s own perl modules have a time leap forward.

FreeBSD comes with support for multiple software RAID implementations to date.

• ata, which is not really a RAID toolkit but the ata device driver itself.Nevertheless it provides sort of RAID functionality by also interfacing to popular low-end RAID controllers, sometimes also referred to as Fake-RAID controller (highpoint, promise and alike).
  It has support for enabling RAID on non-RAID capable ata controllers, too.ata is IMHO the worst RAID solution out there, and as such should be avoided at any cost. Please read as I’m writing: I’m not telling you the ata driver is bad, but I think it shouldn’t tamper with RAID.
  RAID should never be implemented by means of a device driver which does some scary magic inside. A real RAID controller (hardware RAID) or a volume manager (software RAID) should be used instead.
• ccd, the concatenated disk driver, used to be a standalone framework in previous FreeBSD versions. It has been integrated with geom (geom_ccd) in FreeBSD 5 and IMHO seems only to exist for historical and backward compatibility reasons by today.
• vinum was also a standalone RAID framework in previous FreeBSD versions. It too was merged into geom (geom_vinum) in FreeBSD 5.
• geom, which is basically an I/O abstraction layer which serves as stackable framework to multiple subsystems like vinum volume manager (which does jbod, raid 0, raid 1, raid 5 and combinations thereof), mirror (which does raid1), stripe (raid0), and many others.geom provides both functionality and reliability in a proper implementation. I think it might outrun big players like Veritas Volume Manager one day.

So what I’m going to do is a performance comparison (benchmark) of the different geom classes providing RAID1 (mirroring), RAID0 (striping) and RAID10 functionality.

I will neither review ata’s RAID capability nor the geom_ccd class for the obvious reaons mentioned before.

All tests have been taken on a Sun E450 with 4 ultraSparc-II CPUs @ 400 MHz. It has 1 GB RAM aside and 6 disks (SEAGATE ST318404LSUN18G) interfaced to the Symbios Logic scsi host bus.

To get accurate results, all tests were run five times, takeing the average values from all tests.

Testing was done using three methods.

• rawio was used to get low level I/O performance for the geom consumer under a concurrent load simulation (multiple tasks reading/writing in parallel).
• dd was used to get low level I/O performance for the geom consumer in sequential read and write (single task).Sequential read was tested by writing 256 MB of data from the consumer to /dev/null useing block sizes from 16k to 1m. /dev/null was used as output device to circument I/O bound rate limits while reading from the provider.Sequential write was tested by writing 256 MB of data from /dev/zero to the consumer useing block sizes from 16k to 1m. /dev/zero was used as input device to circument I/O bound rate limits while writing to the provider.
• bonnie++ was used to get pure filesystem performance by writing/reading 1 GB files.

I must admit that these tests are truely synthetical and do not reflect actual performance to be expected in a production grade environment. But this was not the idea of these tests anyway.
What I wanted to see was if there is a difference in the geom classes in terms of their pure performance and the overhead the impose, basically if there is a “winner” and a “looser” amongst the different implementations.

You may want to check out my upcoming articles on these topics to learn more:

FreeBSD software RAID comparison: gvinum RAID1 vs. gmirror
FreeBSD software RAID comparison: gvinum RAID0 vs. gstripe
FreeBSD software RAID comparison: gvinum RAID10 vs. gmirror+gstripe
FreeBSD software RAID comparison: gvinum RAID5

And don’t forget: the results shown later on reflect the performance on my particular hardware. There is no guarantee to get the same results on different hardware. It is very likely though that the results found here will be similar comparing the overall performance and the overhead ratio on other platforms.