くだらない質問はここに書き込め!44

Linuxからあるディレクトリごとまるごとcpしたんだけど、
Linuxで314MBあった内容が、NetBSDでは243MBになった。
これはブロックのサイズが4096と512の違いだけが理由なの？

補足ですが、サイズはdu -shで測りました

sshで次々と不正な進入を試みるホストを自動で遮断することはできないですかね？

>>804
ssh LOGの監視、ホスト/ポート指定遮断、それらを連携して行える環境、
何れも材料は整ってる。
だからどうとでもなる。

「Linuxのブートプロセスをみる」のように、
**BSDのブート周りが書いてある書籍、websiteってありませんでしょうか。

>>802
またコピーし戻してみりゃいいんで無いの？NetBSD->Linux

>>806
FreeBSDならハンドブックに書いてあるぞ
Chapter 7. FreeBSD の起動のプロセス
http://www.jp.freebsd.org/www.FreeBSD.org/doc/ja_JP.eucJP/books/handbook/boot.html

>>802
> これはブロックのサイズが4096と512の違いだけが理由なの？

ファイルシステムにフラグメント機能があるかないかの違いじゃない?
NetBSD でもブロックサイズは 4096 か 8192 になってると思うよ。
でも、末尾のブロックだけは 512 か 1024 単位のフラグメントで
割り当ててる。

>>802
cp だといわゆる「穴の開いたファイル」の扱いが正しく行われないのでそういう事態もおこりうる
というのが昔から議論されている
詳しくはぐぐれ

>>810
その場合はサイズが増える
>>809が正解じゃないか

>>809
それは小さいファイルが沢山あるような場合に有利ということなんでしょうか？
ファイルシステムはext3(Linux)、ffs(NetBSD)です。
dumpe2fsでext3を見たらBlock size、Fragment sizeともに4096でした。
NetBSDのファイルシステム情報のチェックの仕方はちょっと不明、でも
ファイル数の少ないディレクトリは512と表示されているのでフラグメントサイズは
512ということになるんでしょうか。

>>812
disklabel wd0 で表示される fsize、bsize がそれ。

ファイルのサイズが一様に分布していたとすると、
全ファイル数*fragment size*0.5無駄な領域となる。

計算してみれ。

>>813
ffsではfsizeが1024、bsizeが8192でした。ファイル数は33443。

ffsで無駄になってそうなバイト数
33443 * 1024 * 0.5 = 17,122,816
ext3で無駄になってそうなバイト数
33443 * 4096 * 0.5 = 68,491,264
68MB - 17MB = 51MB

こんな感じでしょうか。fsizeとbsizeによって
結構無駄な領域って発生するもんですね。

ext2/ext3でもフラグメントを実装しようとした痕跡はあるんだけどね。
途中で投げ出したんだろう。