« HDL2-G2.0にnetatalk 2.2.0をインストール(その6) | トップページ | HDL2-G2.0にnetatalk 2.2.1をインストール »

2011.09.20

HDL2-G2.0にnetatalk 2.2.0をインストール(その7・最終回)

前回まででTime Machineは動作しましたが、(やり方が悪かったのか)volsizelimit:オプションがうまく動作しなかった(設定すると残りの容量が0になってバックアップに失敗する)ので、別のアプローチで解決する事にしました。
ディスクイメージの上限を制限しないと、さすがに、NASの容量をTime Machineで使い尽くす訳にいきませんので。
ほとんど、以下のサイトの説明のままです。ありがとうございます。
Time Capsuleのバックアップ容量に制限をかける方法 App in the air
TimeCapsuleのバックアップ容量に制限をかける tune web 日々の出来事の記録

まず、ディスクユーティリティを用いてローカル(デスクトップでいいです)にディスクイメージを作成します。
ディスクユーティリティのメニュー
ファイル→新規→空のディスクイメージ
から、イメージフォーマットをスペースバンドル・ディスクイメージを設定します。名前はとりあえず適当で。

名前 適当
サイズ カスタムから、バックアップ対象ディスク容量の1.5倍程度を設定(自分の場合、後から、パーティションの設定画面から設定した)
フォーマット Mac OS 拡張(ジャーナリング)
暗号化 なし
パーティション 単一パーティション Appleパーティションマップ
イメージフォーマット スペースバンドル・ディスクイメージ 

これで、ディスクイメージ完成。

なお、ここでGbyte単位で設定しても、作成されたディスクイメージフォルダの容量がGbyte単位になる訳ではありません。保存しただけ、随時拡張されるようです。

Time Machineの環境設定からディスクを選択して今回のバックアップを置くフォルダにバックアップ作成。途中でキャンセル。
作成されたバックアップのディスクイメージのフォルダ名をエディタにでもコピー。
多分、“自分のコンピュータ名”.sparsebudleというフォルダができていますが、このフォルダの中の”com.apple.TimeMachine.MachineID.plist”を適当な場所に退避。(Finderからの場合、”パッケージの内容を表示”からフォルダの中身を表示してコピー可能です。)
この作成途中で作成をキャンセルされたフォルダを削除。

上で作成したローカルのディスクイメージをNASのバックアップ先フォルダにコピー。
コピーしたディスクイメージの名称を上でコピーした名称に変更。
上で退避した”com.apple.TimeMachine.MachineID.plist”をバックアップ・イメージのフォルダ内にコピー。

これで、Time Machine からバックアップを作成すれば、容量が上で設定されたものに制限された範囲でバックアップが作成されます。(「”Time Machine”環境設定を開く」からでは正確な残り容量が分からないのですが…)

なぜ、/etc/netatalk/AppleVolumes.defaultにおいてvolsizelimit: 指定が有効に動作しないか(設定すると残り容量が0になってバックアップに失敗する)の原因は分かっていません。

ともあれ、これでHDL2-GをTime Machineのバックアップ作成先として使用できるようになりました。
DHX2認証によりLionからNASに認証付きで接続可能となりました。
これでHDL2-Gへのnetatalk 2.2.0導入手順記事は最終回とします。

(その後、netatalk 2.2.1にアップデートしていますので、もう一回(?)続きます。)

|

« HDL2-G2.0にnetatalk 2.2.0をインストール(その6) | トップページ | HDL2-G2.0にnetatalk 2.2.1をインストール »

NAS」カテゴリの記事

コメント

お願いがあります。
その"TimeMachine2"をMacにマウントした状態で、
MacのTerminal.app上で
#df -h
を実行してもらえないでしょうか。
少なくとも私のnetatalk 2.2.1の場合、volsizelimitを設定していないと実際の空き容量が表示されます。
volsizelimit:2048を設定した場合は、以下のようの表示されます。
#df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/disk0s2 465Gi 151Gi 314Gi 33% /
devfs 183Ki 183Ki 0Bi 100% /dev
map -hosts 0Bi 0Bi 0Bi 100% /net
map auto_home 0Bi 0Bi 0Bi 100% /home
afp_1l2It118QifL1KpKkT0gvJeo-4.2e000008 2.0Gi 2.0Gi 0Bi 100% /Volumes/Backup

投稿: HAT | 2011.09.20 22:37

volsizelimit:512000を設定した場合は、以下のように表示されます。
#df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/disk0s2 465Gi 151Gi 314Gi 33% /
devfs 183Ki 183Ki 0Bi 100% /dev
map -hosts 0Bi 0Bi 0Bi 100% /net
map auto_home 0Bi 0Bi 0Bi 100% /home
afp_1l2It118QifL1KpKkT0gvJeo-4.2e000009 500Gi 441Gi 59Gi 89% /Volumes/Backup

設定によっては残りの容量がゼロになります。

投稿: HAT | 2011.09.20 22:43

HAT様
コメントありがとうございます。

volsizelimit: 設定なし
$ df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/disk0s2 79Gi 52Gi 27Gi 67% /
devfs 184Ki 184Ki 0Bi 100% /dev
map -hosts 0Bi 0Bi 0Bi 100% /net
map auto_home 0Bi 0Bi 0Bi 100% /home
/dev/disk0s4 32Gi 19Gi 13Gi 60% /Volumes/BOOTCAMP
afp_4scGN247DZqa3s7v0V0wSRDl-9.2e000006 928Gi 400Gi 529Gi 44% /Volumes/TimeMachine2

投稿: tonop | 2011.09.21 02:05

volsizelimit:100000 指定

$ df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/disk0s2 79Gi 52Gi 27Gi 67% /
devfs 184Ki 184Ki 0Bi 100% /dev
map -hosts 0Bi 0Bi 0Bi 100% /net
map auto_home 0Bi 0Bi 0Bi 100% /home
/dev/disk0s4 32Gi 19Gi 13Gi 60% /Volumes/BOOTCAMP
afp_4scGN247DZqa3s7v0V0wSRDl-9.2e000007 98Gi 98Gi 0Bi 100% /Volumes/TimeMachine2

??? volsizelimit:指定がうまくいってるみたいですね。
試しにTime Machine のディスクを選択し直してみると、空き容量が、"Time Machine"環境設定画面上で
0KB/104.86GBと表示されて、やはりバックアップを失敗しました。
(netatalk 2.2.1 の上でテスト)

投稿: tonop | 2011.09.21 02:23

これって、実際に使用している容量より小さい値をvolsizelimit:に設定しているので残りがゼロになっているだけでは?

投稿: HAT | 2011.09.21 03:14

コメントありがとうございます。

新規でバックアップを作成する際に、最初から
空き容量: 0KB/104.86GB
と出ますので(上のvolsizelimit:指定有りの場合)、volsizelimit:制限より多く使用していることが原因ではないと思います。

上の例の場合、バックアップ対象が79GB(BOOTCAMPは対象外)なので、98GB指定で容量としては足りていると思います。

投稿: tonop | 2011.09.21 19:46

なので、前回のコメントが不正確で、
afp_4scGN247DZqa3s7v0V0wSRDl-9.2e000007 98Gi 98Gi 0Bi 100% /Volumes/TimeMachine2
は、いきなり使い切った結果が出ているのが、問題ということでしょうか。

投稿: tonop | 2011.09.21 19:51

ううむ、そうですか。バグかもしれない。
ちょっと確認してみます。

投稿: HAT | 2011.09.21 22:52

手元のFedora 15上のnetatalk 2.2.1で試しましたが、再現しません。
こういう事例は今のところ報告がありません。
もしかして、volsizelimitを設定する前にバックアップを試していて、
ディスクイメージが作成されていませんでしたか?
または、全く別のデータが該当ボリューム上にあったとか。

投稿: HAT | 2011.09.22 00:12

コメントありがとうございます。

当該フォルダ(自分の場合"TimeMachine2")にはバックアップを置かない状態で試しましたので、これが原因という事はないと思います。
他に置いてあったファイルといえばNetwark Trash FolderとかTemporary Itemsなので悪さをするとも思えません。
ARM環境(しかもDebian etchと少々古い)でのconfigure & makeなので、マイナーな環境と言えるところで発生していますので…

投稿: tonop | 2011.09.22 08:58

etc/afpd/volume.cの該当部分

getvolspace_done:
if (vol->v_limitsize) {
if (getused(vol) != 0)
return AFPERR_MISC;
LOG(log_debug, logtype_afpd, "volparams: used on volume: %" PRIu64 " bytes",
getused_size);
vol->v_tm_used = getused_size;

*xbtotal = min(*xbtotal, (vol->v_limitsize * 1024 * 1024));
*xbfree = min(*xbfree, *xbtotal < getused_size ? 0 : *xbtotal - getused_size);
}

*bfree = min( *xbfree, maxsize);
*btotal = min( *xbtotal, maxsize);

getused_sizeよりもvolsizelimitで指定した値が小さい場合、残容量はゼロになる。
このgetused_sizeの算出方法がややこしい。このあたりの問題かも。

投稿: HAT | 2011.09.23 00:07

afpd.confに、
-setuplog "default log_debug /var/log/netatalk.log"
というのを追加すると、/var/log/netatalk.logに
{volume.c:1546} (D5:AFPDaemon): volparams: used on volume: XXXX bytes
という感じでgetused_sizeが表示されます。
この値がどうなってるかが問題ですね。

投稿: HAT | 2011.09.23 00:11

HAT様

コメントありがとうございます。お手間をおかけしておりまして申し訳ないです。
volsizelimit:指定なしの場合
{volume.c:1546} (D5:AFPDaemon): volparams: used on volume: XXXX bytes
の行は無し

volsizelimit:100000 指定ありの場合
Sep 23 19:54:11.316330 afpd[1718] {volume.c:1546} (D5:AFPDaemon): volparams: used on volume: 7213566707504637952 bytes
別のタイミングでは
Sep 23 19:54:58.151261 afpd[1718] {volume.c:1546} (D5:AFPDaemon): volparams: used on volume: 4292152819655310336 bytes
というわけで、あり得ないくらい大きい容量を使い果たしているように見えます。(このNASには1Gx2しか積んでいない)

投稿: tonop | 2011.09.23 20:07

すいません。ミス。
このNASには1Gx2しか積んでいない → このNASには1Tx2しか積んでいない

投稿: tonop | 2011.09.23 20:09

ちょっと確認ですが、configureの最後に表示されるsummaryで、
Configure summary:
Install style:
debian
AFP:
Large file support (>2GB) for AFP3: yes
Extended Attributes: ad | sys

このLarge file supportはyesだったでしょうか。

投稿: HAT | 2011.09.23 21:52

netatalk 2.2.1の場合ですが、

Configure summary:
Install style:
debian
AFP:
Large file support (>2GB) for AFP3: yes
Extended Attributes: ad | sys
CNID:
backends: dbd last tdb
UAMS:
DHX ( SHADOW)
DHX2 ( SHADOW)
RANDNUM ( SHADOW)
passwd ( SHADOW)
guest
Options:
DDP (AppleTalk) support: no
SLP support: no
Zeroconf support: yes
tcp wrapper support: no
quota support: yes
admin group support: yes
valid shell check: yes
cracklib support: no
dropbox kludge: no
force volume uid/gid: no
ACL support: yes
LDAP support: no

でした。

投稿: tonop | 2011.09.24 04:51

Paralles Desktop上のDebian Etchにて、configure summaryを完全一致するようにしてからnetatalk 2.2.1をインストールして再現実験を行ないました。結果、再現しました。

Mac側のdf -hの結果:
afp_3k5HxT4FabGL2A1VRd4t2RKG-2.2e000006 1.0Gi 1.0Gi 0Bi 100% /Volumes/backup_test

netatalkのログ:
Sep 25 01:33:36.424722 afpd[22661] {volume.c:1546} (D5:AFPDaemon): volparams: used on volume: 7416679366656 bytes

7TB使っていることになってます。ありえません。
つまりIntelだろうがARMだろうが発生します。
明らかにバグです。
Etch側のバグか、netatalk側のバグかは、まだ不明。

投稿: HAT | 2011.09.25 01:51

HAT様

コメントありがとうございます。
思い起こすと、確かにVMware Fusion上のEtch環境で試した時に容量が足りない旨のエラーが出ていました。その時は、もともとローカルにバックアップをとるだけの容量が確保できておらず、そのせいだと流してしまってました。流しちゃいけなかったんですね。
反省。

投稿: tonop | 2011.09.25 03:12

その後lennyとsqueezeでも試してみましたが、問題ありませんでした。
etchのみで発生するようです。

メーリングリストで報告済。
http://sourceforge.net/mailarchive/forum.php?thread_name=20110926.215511.531989076.hat%40fa2.so-net.ne.jp&forum_name=netatalk-devel

投稿: HAT | 2011.09.26 22:01

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/1024423/41795522

この記事へのトラックバック一覧です: HDL2-G2.0にnetatalk 2.2.0をインストール(その7・最終回):

« HDL2-G2.0にnetatalk 2.2.0をインストール(その6) | トップページ | HDL2-G2.0にnetatalk 2.2.1をインストール »