(FreeBSD) zpool replaceするつもりがzpool addしてしまって、ゲゲゲな結果になった

FreeBSDでZFSを使って数年、えっ？そうだったんだ…、ということがありました。

もともと、1.5TBディスク４本を使ったraidzなプールがありました。

運用開始後、ディスクでエラーが発生してディスクを交換したのですが、そのころには、2TBのディスクが安くなっていたので、2TBのディスクを使いました。2TBのディスクを使っても、raidzでは一番小さい容量のディスクにあわせてプールが構成されるので、2TBのディスクを使っても、1.5TB分だけ使われているらしく、プールの容量は同じまま。

ディスク交換をこれまで２回行って、raidzなプールは、1.5TBのディスク2本、2TBのディスク2本で構成されていました。

どうせなら、全部2TBのディスクに交換してしまえ、そうすればプールの容量が大きくなる・・・と思いまして、1.5TBディスクを1本抜いて、新しい2TBディスクを接続。

そして、

zpool replace プール名 新ディスク

というコマンドを実行すべきところ、まちがえて

zpool add プール名 新ディスク

とやってしまいました。

たしかresilverとかいう表示になって、raidzほにゃららの再構成が始まるはず・・・と思ってたら、なかなかそうならない。

なんということでしょう・・・
zpool add なので、プールにディスクを追加して、プールの容量を大きくしちゃったじゃないですか。

1.5TBのディスク3本分の容量のraidz1のプールと、2TBのディスク1本をくっつけた、でかいプールへ、容量が拡大されてしまいました。

zpool addしたのを取り消すのは、zpool removeかな？　あれ、できないぞ。おかしいな。

だんだん事態が理解できてきました。

今のZFSって、プールのサイズ拡大はできるけど、サイズ縮小って、できないんですね・・・
zpool addしちゃったら、もうディスクを抜くことはできない、ということ。

しょうがないので、zfs sendで、別のサーバにすべてのデータを移して、プールをゼロから作り直すことにしました

Windowsのエクスプローラーで、名前順で並べたときのソート規則

今頃気がついたこと。

以下はWindows7のエクスプローラーで、名前でソートしたときの並び順序なのですが、

ファイル名が数値だと、数値の大小関係でソート（numeric sort）しているんですね。たとえば「999」のほうが先に来て、「201310」のほうが後になります。

文字コードでソート、辞書式順序、とかだと思っていました。ファイル名を「年月」（201310.txt）と「年月日」（20131021.txt）とを混ぜて使っていたら、わけわからん状態になって、なんでこうなってんの？！と思いました。

Unix系OSでおなじみのlsコマンドでのデフォルトのソート順序は、

という感じになります。つまり、「1」で始まるファイル名が先になり、「9」で始まるファイル名の方が後になります。

Windows XPのエクスプローラーも、数値の大小でソートしてたんですね。気がつきませんでした

 

(FreeBSD) /usr/bin/file -L --mime-type すると application/x-symlink と出てくる

portsでビルドするときに、とある共有ライブラリがインストールされていない、と誤判定されるので、調べてみた。

誤判定の原因は「file -L」コマンドの出力。

# /usr/bin/file -L --mime-type /usr/local/lib/libdconf.so
/usr/local/lib/libdconf.so: application/x-symlink

「file -L」は、symbolic linkで参照する先の情報を返すはずなのに、なぜかそうならない。

# ls -l /usr/local/lib/libdconf.so*
lrwxr-xr-x  1 root  wheel     13  3月  9  2013 /usr/local/lib/libdconf.so -> libdconf.so.0
-r-xr-xr-x  1 root  wheel  35236  3月  9  2013 /usr/local/lib/libdconf.so.0

ためしに別のFreeBSD 8.4なホストで同じコマンドを実行してみると

> /usr/bin/file -L --mime-type /usr/local/lib/libdconf.so
/usr/local/lib/libdconf.so: application/x-sharedlib

となって、こちらは正常。ちゃんとsymbolic linkの先を見て判定している。

とりあえずktraceしてみたら、

38039 file     NAMI  "/usr/local/lib/libdconf.so"
38039 file     STRU  struct stat {dev=107, ino=354962, mode=lrwxr-xr-x , nlink=
1, uid=0, gid=0, rdev=1684171116, atime=1362790516, stime=1362790516, ctime=1362
790516, birthtime=1362790516, size=13, blksize=16384, blocks=0, flags=0x0 }
38039 file     RET   lstat 0
38039 file     CALL  readlink(0xbfbfe885,0xbfbfd534,0x3ff)
38039 file     NAMI  "/usr/local/lib/libdconf.so"
38039 file     RET   readlink 13/0xd
38039 file     CALL  stat(0xbfbfcd30,0xbfbfccd0)
38039 file     NAMI  "/usr/local/lib/libdconf.so.0"
38039 file     STRU  struct stat {dev=107, ino=354912, mode=-r-xr-xr-x , nlink=
1, uid=0, gid=0, rdev=1464768, atime=1379105689, stime=1362790516, ctime=1362790
516, birthtime=1362790516, size=35236, blksize=16384, blocks=72, flags=0x0 }
38039 file     RET   stat 0
38039 file     CALL  write(0x1,0x33e03000,0x32)
38039 file     GIO   fd 1 wrote 50 bytes
       "/usr/local/lib/libdconf.so: application/x-symlink
       "
38039 file     RET   write 50/0x32

という感じで、ちゃんとreadlinkもして"/usr/local/lib/libdconf.so.0"を見に行っているようにも見えるけど、なぜなんだろう。

正常に動いているホストと、正常に動かないホストとを、ざっくりと比較してみる。

正常なホスト。

> kdump | grep NAMI
19755 ktrace   NAMI  "/usr/bin/file"
19755 ktrace   NAMI  "/libexec/ld-elf.so.1"
19755 file     NAMI  "/etc/libmap.conf"
19755 file     NAMI  "/var/run/ld-elf.so.hints"
19755 file     NAMI  "/lib/libmagic.so.4"
19755 file     NAMI  "/usr/lib/libmagic.so.4"
19755 file     NAMI  "/usr/lib/libmagic.so.4"
19755 file     NAMI  "/lib/libz.so.5"
19755 file     NAMI  "/lib/libz.so.5"
19755 file     NAMI  "/lib/libc.so.7"
19755 file     NAMI  "/lib/libc.so.7"
19755 file     NAMI  "/home/yoshin-t/.magic"
19755 file     NAMI  "/etc/malloc.conf"
19755 file     NAMI  "/usr/share/misc/magic.mime.mgc"
19755 file     NAMI  "/usr/share/misc/magic.mgc"
19755 file     NAMI  "/usr/local/lib/libdconf.so"
19755 file     NAMI  "/usr/local/lib/libdconf.so"
19755 file     NAMI  "/usr/local/lib/libdconf.so"

正常じゃないホスト。

# kdump |grep NAMI
38039 ktrace   NAMI  "/usr/bin/file"
38039 ktrace   NAMI  "/libexec/ld-elf.so.1"
38039 file     NAMI  "/etc/libmap.conf"
38039 file     NAMI  "/var/run/ld-elf.so.hints"
38039 file     NAMI  "/lib/libmagic.so.4"
38039 file     NAMI  "/usr/lib/libmagic.so.4"
38039 file     NAMI  "/usr/lib/libmagic.so.4"
38039 file     NAMI  "/lib/libz.so.5"
38039 file     NAMI  "/lib/libz.so.5"
       0x0ce0 1200 0a00 005f 4459 4e41 4d49 4300 5f47  |....._DYNAMIC._G|
38039 file     NAMI  "/lib/libc.so.7"
38039 file     NAMI  "/lib/libc.so.7"
38039 file     NAMI  "/usr/share/locale/ja_JP.eucJP/LC_CTYPE"
38039 file     NAMI  "/etc/malloc.conf"
38039 file     NAMI  "/root/.magic"
38039 file     NAMI  "/usr/share/misc/magic.mime.mgc"
38039 file     NAMI  "/usr/share/misc/magic.mime.mgc"
38039 file     NAMI  "/usr/share/misc/magic"
38039 file     NAMI  "/usr/share/misc/magic"
38039 file     NAMI  "/usr/local/lib/libdconf.so"
38039 file     NAMI  "/usr/local/lib/libdconf.so"
38039 file     NAMI  "/usr/local/lib/libdconf.so.0"

正常じゃないホストでは、"/usr/share/misc/magic.mime.mgc"というファイルをアクセスしているらしい。

正常なホスト

> ls -l /usr/share/misc/magic*
-r--r--r--  1 root  wheel   536241 Jul 14 10:06 /usr/share/misc/magic
-r--r--r--  1 root  wheel  1751200 Jul 14 10:06 /usr/share/misc/magic.mgc

正常じゃないホスト

# ls -l /usr/share/misc/magic*
-r--r--r--  1 root  wheel   536241  7月 20 12:17 /usr/share/misc/magic
-r--r--r--  1 root  wheel  1751200  7月 20 12:17 /usr/share/misc/magic.mgc
-r--r--r--  1 root  wheel    33539 10月 21  2009 /usr/share/misc/magic.mime
-r--r--r--  1 root  wheel    46208 10月 21  2009 /usr/share/misc/magic.mime.mgc

正常じゃないホストでは、/usr/share/misc/magic.mime.mgc とか、タイムスタンプの古いファイルがある。旧バージョンのときのファイルが残っていたのだろうか？

ためしに、ファイルmagic.mime*を、別の場所へ待避させてみる。

# mkdir /usr/share/misc-
# mv /usr/share/misc/magic.mime* /usr/share/misc-/
# /usr/bin/file -L --mime-type /usr/local/lib/libdconf.so
/usr/local/lib/libdconf.so: application/x-sharedlib

直った！

ちなみに、「-L」オプションを付けないときは、symbolic linkだと判定され、これは正常。

# /usr/bin/file --mime-type /usr/local/lib/libdconf.so
/usr/local/lib/libdconf.so: application/x-symlink

(FreeBSD) thunderbird-17.0.7でBus error

Firefoxにつづいて、ThunderbirdでもBus error

% thunderbird
Bus error

たぶん

FreeBSD 8.4でportsのwww/firefoxでビルドしたfirefox-21がいきなりBus errorで動かない

と同じでしょ？と思い、OPTIMIZED_CFLAGSをオフにしてビルドし直してみましたが、やはりBus error

ネット検索してみると、よくにた症状の報告を発見。ktraceの様子もそっくり。

http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2012-August/237571.html
http://www.freebsd.org/cgi/query-pr.cgi?pr=170310

へ～LDAPが原因ですか・・・って、あれ？なんかどっかであったような。

２年前の

(FreeBSD) nsswitch.confでLDAPが有効になっているとthunderbirdが起動しない

と同じみたいでした

とりあえず、thunderbirdを実行するユーザのアカウントを/etc/passwdで登録しておけばOK。

FreeBSD 8.4でportsのwww/firefoxでビルドしたfirefox-21がいきなりBus errorで動かない

もうportsはfirefox-22になってしまっていますが・・・

FreeBSD 8.4なマシンで、portsのwww/firefoxでビルドしたfirefox-21なのですが、起動するといきなりBus errorが出て動きません。

% firefox
Bus error

すぐにBus errorとなってしまい、profile managerさえも出せません。

もともとFreeBSD 8.2Rだったのを、最近8.4へアップデートしたばかりだったので、portupgradeしまくってみたものの、Bus errorでうんともすんとも言わず。

ネット検索してみたところ、同様の報告が見つかりました。

http://forums.freebsd.org/showthread.php?t=40453
http://lists.freebsd.org/pipermail/freebsd-ports/2013-May/thread.html#83601
http://lists.freebsd.org/pipermail/freebsd-ports/2013-May/083601.html

make configしてOPTIMIZED_CFLAGSをオフにすればいい、だそうです。

そういえば、以前、そのOPTIONをオンにしたことがありました。

オフにしてfirefoxをビルドしなおすと、動きました

FreeBSD 9.1Rでは、まったく問題ないのですが、自分が見た範囲では、8.4RでだけBus errorが出てました。
FreeBSD 8.2Rだと、firefox18あたりから、ビルド中にエラーが出ててアップデートできなかったので、firefox21で初めてこの現象が起きたのかどうかはわかりません。

IIJmio (2)

IIJmioのミニマムスタートプラン（月額945円）を使い始めて、はや１年。

最初は、通信速度が128kbpsに制限されていたのが、いつまにか200kbpsに緩和されていたり

https://www.iijmio.jp/info/iij/20130321-1.html
プラン名称変更・サービス仕様改定のお知らせ（IIJmio高速モバイル/Dサービス）

さらには、1ヶ月500MBまでなら、速度制限が無くなってしまったり

https://www.iijmio.jp/info/iij/20130426-2.html
「増量先取り！ご愛顧感謝キャンペーン」のお知らせ（IIJmio高速モバイル/Dサービス）

何ですか、このうれしい対応は
ライバル企業と競争してくれることで、利用者はうれしい思いをする、ってことですか。

でもって、自分の場合、１ヶ月の通信量は500MBいかないようです。

それでですね、あまった分は、翌月に繰り越しできるんですと（でも、有効期限は次の月の月末まで）。

でもって、１ヶ月９４５円。自分にはとってもお得です。

あと、某公衆Wi-Fiサービスは、使い物にならないので、解約しちゃいました

■ 過去記事

• IIJmio

USBで充電するケーブル

用事があって実家に帰ってきたのですが、3DS、デジカメ、Wi-Fiルータなどを充電するためのケーブルを持ってくるのを忘れました

しょうがないので、１００円ショップで買ってきました。

ただ、なかなか売って無くて、３店も、はしごしました・・・

１店目は、売ってなかった。

２店目は、3DSのケーブルだけ買えた。

３店目で、microUSBなケーブルが買えた。

なんでこうなってるんですかね、同じダイソーなのに・・・

lmutil: Command not found.

知る人ぞ知るlmutilとかlmstatというコマンドに関して・・・

CentOS6なホストがいくつかあるのですが、ホストによって、動いたり動かなかったり。

% /なんとか/かんとか/lmutil
/なんとか/かんとか/lmutil: Command not found.

動かない・・・なぜ？

% file lmutil
lmutil: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped

動くホストで、ldd lmutilして確認してみると

/lib64/ld-lsb-x86-64.so.3 => /lib64/ld-linux-x86-64.so.2 (0x00007faf9bf9e000)

という、「ldなんとか.so」のところで、違いがあるようです。

うごかないホストでは
% ls -l /lib64/ld*
-rwxr-xr-x. 1 root root 154464 Jan 31 20:30 /lib64/ld-2.12.so*
lrwxrwxrwx. 1 root root     10 Feb  6 18:03 /lib64/ld-linux-x86-64.so.2 -> ld-2.

うごくホストでは
% ls -l /lib64/ld*
-rwxr-xr-x 1 root root 154464 Feb 21 22:12 /lib64/ld-2.12.so*
lrwxrwxrwx 1 root root     10 May 30 16:51 /lib64/ld-linux-x86-64.so.2 -> ld-2.12.so*
lrwxrwxrwx 1 root root     20 May 30 16:58 /lib64/ld-lsb-x86-64.so -> ld-linux-x86-64.so.2*
lrwxrwxrwx 1 root root     20 May 30 16:53 /lib64/ld-lsb-x86-64.so.3 -> ld-linux-x86-64.so.2*

straceしてみたり

% strace lmutil
execve("lmutil", ["/なんとか/かんとか"...], [/* 47 vars */]) = -1 ENOENT (No such file or directory)
dup(2)                                  = 3
fcntl(3, F_GETFL)                       = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 6), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffaafc85000
lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
write(3, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
close(3)                                = 0
munmap(0x7ffaafc85000, 4096)            = 0
exit_group(1)                           = ?

なぜexecveで「No such file or directory」なのかよくわからなかったり。

というわけでネット検索。

http://stackoverflow.com/questions/5234088/execve-file-not-found-when-stracing-the-very-same-file

ふむ。

ld-lsb-x86-64.soでネット検索したりしてたら、わかりました。

http://software.intel.com/en-us/articles/flexlm-license-manager-20-may-fail-when-lsb-3-is-not-met

Linuxには「LSB」とかいうものがあるそうです。

http://ja.wikipedia.org/wiki/Linux_Standard_Base

動くホストでは、「redhat-lsbなんとか」というRPMパッケージがインストールされていました。

% rpm -q -a | grep redhat-lsb
redhat-lsb-compat-4.0-7.el6.centos.x86_64
redhat-lsb-printing-4.0-7.el6.centos.x86_64
redhat-lsb-4.0-7.el6.centos.x86_64
redhat-lsb-core-4.0-7.el6.centos.x86_64
redhat-lsb-graphics-4.0-7.el6.centos.x86_64

% lsb_release
LSB Version:    :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch

一方、動かないホストでは、redhat-lsbは１つもインストールされていませんでした。

というわけで、yum install redhat-lsb して解決。

えらくたくさんインストールされましたが

Dependencies Resolved

================================================================================
Package                     Arch      Version                 Repository  Size
================================================================================
Installing:
redhat-lsb                  x86_64    4.0-7.el6.centos        base        11 k
Installing for dependencies:
at                          x86_64    3.1.10-43.el6_2.1       base        60 k
bc                          x86_64    1.06.95-1.el6           base       110 k
cdparanoia-libs             x86_64    10.2-5.1.el6            base        47 k
cvs                         x86_64    1.11.23-15.el6          base       711 k
ed                          x86_64    1.1-3.3.el6             base        72 k
foomatic                    x86_64    4.0.4-1.el6_1.1         base       251 k
foomatic-db                 noarch    4.0-7.20091126.el6      base       980 k
foomatic-db-filesystem      noarch    4.0-7.20091126.el6      base       4.4 k
foomatic-db-ppds            noarch    4.0-7.20091126.el6      base        19 M
gettext                     x86_64    0.17-16.el6             base       1.8 M
gstreamer-plugins-base      x86_64    0.10.29-2.el6           base       940 k
libmng                      x86_64    1.0.10-4.1.el6          base       165 k
liboil                      x86_64    0.3.16-4.1.el6          base       121 k
libtheora                   x86_64    1:1.1.0-2.el6           base       129 k
libvisual                   x86_64    0.4.0-9.1.el6           base       135 k
pax                         x86_64    3.4-10.1.el6            base        69 k
perl-CGI                    x86_64    3.51-131.el6_4          updates    208 k
perl-ExtUtils-MakeMaker     x86_64    6.55-131.el6_4          updates    292 k
perl-ExtUtils-ParseXS       x86_64    1:2.2003.0-131.el6_4    updates     44 k
perl-Test-Harness           x86_64    3.17-131.el6_4          updates    230 k
perl-Test-Simple            x86_64    0.92-131.el6_4          updates    111 k
perl-devel                  x86_64    4:5.10.1-131.el6_4      updates    421 k
phonon-backend-gstreamer    x86_64    1:4.6.2-26.el6_4        updates    126 k
qt                          x86_64    1:4.6.2-26.el6_4        updates    3.9 M
qt-sqlite                   x86_64    1:4.6.2-26.el6_4        updates     51 k
qt-x11                      x86_64    1:4.6.2-26.el6_4        updates     12 M
qt3                         x86_64    3.3.8b-30.el6           base       3.5 M
redhat-lsb-compat           x86_64    4.0-7.el6.centos        base        10 k
redhat-lsb-core             x86_64    4.0-7.el6.centos        base        25 k
redhat-lsb-graphics         x86_64    4.0-7.el6.centos        base        13 k
redhat-lsb-printing         x86_64    4.0-7.el6.centos        base        11 k
time                        x86_64    1.7-37.1.el6            base        26 k

Transaction Summary
================================================================================
Install      33 Package(s)

Total download size: 46 M

(FreeBSD) tar: Unrecognized archive format

FreeBSD 8.3なマシンで、portsを使っているときの話なのですが、

# uname -r
8.3-RELEASE-p3

最近、「tar: Unrecognized archive format」というエラーを時々見かけるようになりました。たとえば

# portupgrade -p png-1.5.15
--->  Upgrading 'png-1.5.15' to 'png-1.5.16' (graphics/png)
--->  Building '/usr/ports/graphics/png'
===>  Cleaning for png-1.5.16
===>  Found saved configuration for png-1.5.14
===> Fetching all distfiles required by png-1.5.16 for building
===>  Extracting for png-1.5.16
=> SHA256 Checksum OK for libpng-1.5.16.tar.xz.
=> SHA256 Checksum OK for libpng-1.5.16-apng.patch.gz.
tar: Unrecognized archive format
tar: Error exit delayed from previous errors.
*** Error code 1

Stop in /usr/ports/graphics/png.
*** Error code 1

Stop in /usr/ports/graphics/png.

「tar: Unrecognized archive format」ということなので、アーカイブのファイル形式が「.xz」だからでるエラーでしょうかね。
とりあえず、/usr/bin/tarの代わりに、/usr/ports/archivers/gtar/でインストールした、/usr/local/bin/gtar を使わせてしまえばＯＫっぽいです。

# env TAR=gtar portupgrade -p png-1.5.15
--->  Upgrading 'png-1.5.15' to 'png-1.5.16' (graphics/png)
--->  Building '/usr/ports/graphics/png'
===>  Cleaning for png-1.5.16
===>  Found saved configuration for png-1.5.14
===> Fetching all distfiles required by png-1.5.16 for building
===>  Extracting for png-1.5.16
=> SHA256 Checksum OK for libpng-1.5.16.tar.xz.
=> SHA256 Checksum OK for libpng-1.5.16-apng.patch.gz.
/bin/cp /usr/ports/distfiles/libpng-1.5.16-apng.patch.gz /ports.work.d/usr/ports/graphics/png/work/libpng-1.5.16/
/usr/bin/gzip -nf -9 -d /ports.work.d/usr/ports/graphics/png/work/libpng-1.5.16/libpng-1.5.16-apng.patch.gz
===>  Patching for png-1.5.16
（以下省略）

portupgradeではなく、makeしたときも、同じエラーになってしまうので、

# make
===>  Found saved configuration for png-1.5.14
===> Fetching all distfiles required by png-1.5.16 for building
===>  Extracting for png-1.5.16
=> SHA256 Checksum OK for libpng-1.5.16.tar.xz.
=> SHA256 Checksum OK for libpng-1.5.16-apng.patch.gz.
tar: Unrecognized archive format
tar: Error exit delayed from previous errors.
*** Error code 1

これは、make TAR=gtarというやりかたもあったり。

# make TAR=gtar
===>  Found saved configuration for png-1.5.14
===> Fetching all distfiles required by png-1.5.16 for building
===>  Extracting for png-1.5.16
=> SHA256 Checksum OK for libpng-1.5.16.tar.xz.
=> SHA256 Checksum OK for libpng-1.5.16-apng.patch.gz.
/bin/cp /usr/ports/distfiles/libpng-1.5.16-apng.patch.gz /ports.work.d/usr/ports/graphics/png/work/libpng-1.5.16/
/usr/bin/gzip -nf -9 -d /ports.work.d/usr/ports/graphics/png/work/libpng-1.5.16/libpng-1.5.16-apng.patch.gz
===>  Patching for png-1.5.16

ちなみにFreeBSD 9系は、とくに問題ないようです。

☆

あとで
make -d all とかやって調べてみたのですが
gtar -tf FILE.tar.xz はOKで、
gtar -ztf FILE.tar.xz はerror
gtar -jtf FILE.tar.xz もerrorになるようです。へ～、よけいなオプションは付けないほうがいいのですか

(FreeBSD) portsのdatabases/sqlite3で、sqlite3.c:23349

FreeBSD 8.3-RELEASE-p3なマシンにて、portsのdatabases/sqlite3をmakeすると

sqlite3.c:23349: error: 'posix_fallocate' undeclared here (not in a function)

というエラーがでました。

とりあえず、な対処方法。
sqlite-autoconf-3071601のMakefileにて、

DEFS = -DPACKAGE_NAME=\"sqlite\" -DPACKAGE_TARNAME=\"sqlite\" -DPACKAGE_VERSION=\"3.7.16.1\" -DPACKAGE_STRING=\"sqlite\ 3.7.16.1\" -DPACKAGE_BUGREPORT=\"http://www.sqlite.org\" -DPACKAGE_URL=\"\" -DPACKAGE=\"sqlite\" -DVERSION=\"3.7.16.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_USLEEP=1 -DHAVE_LOCALTIME_R=1 -DHAVE_GMTIME_R=1 -DHAVE_DECL_STRERROR_R=1 -DHAVE_STRERROR_R=1 -DHAVE_READLINE=1 -DHAVE_POSIX_FALLOCATE=1

とかなっているので、このなかの「-DHAVE_POSIX_FALLOCATE=1」を削除してから、もう一度、portsのディレクトリにてmakeすればOKな気がします。

なぜconfigureがposix_fallocate()があると勘違いするのかは、よく調べてないのでわかりません

ちなみに、posix_fallocate()は、FreeBSDの8系には無くて、9系だとあるのかも。