/**ファイルシステム総合スレその8**/

/**ファイルシステム� ..

856:login:Penguin
08/09/05 17:37:48 +SJyFP4u
やはり鉛筆と紙だな

857:login:Penguin
08/09/05 18:14:56 kV5sEzEe
>>856
そして、それをOCR…、ってPGPの米国外持ち出しを思い出すな。

858:login:Penguin
08/09/05 20:19:02 K3X7Sr2a
Hansも出所するころには全身にコードが刻み込まれた絵人間に
URLﾘﾝｸ(wiredvision.jp)

859:login:Penguin
08/09/06 16:20:44 Jnd5r4sk
2027年7月7日　Hansあらわる
記者「Hansさん、出所おめでとうございます。」
Hans「いやー有難う。ところでReiserFSのメンテ状況はどう？」
記者「アレは...いや無事に出所できて良かったですね！」

860:login:Penguin
08/09/09 03:49:20 W19H5Uqv
知らない間にハードディスクに、
FAT16（：Ｅ）とReiserFSっていうﾊﾟｰﾃｨｼｮﾝができてたんですが、
これって削除しても大丈夫っぽいですか？　
特にReiserFSがあるとﾊﾟｰﾃｨｼｮﾝ触るときに、「移動できないﾊﾟｰﾃｨｼｮﾝがあるため続行できません」とでてしまい不便してます
URLﾘﾝｸ(www.dotup.org)
URLﾘﾝｸ(www.dotup.org)

調べてみた結果俺みたいなﾊﾟｰﾃｨｼｮﾝ構成になっている人がほとんどいないようだったので、
初期から入ってるものではなくいつの間にか紛れ込んだものだとは思うのですが、
気になるので意見聞かせてください。

ＰＣでテレビを見たことはありません。
一応ＴＶを見れるタイプのＰＣですが設定はしていません。
Linuxのインストール系には手は出してないと思います。

861:login:Penguin
08/09/09 03:55:53 gB41I1Lq
質問する間でもなく、必要のないファイルは消してもいいというのと一緒だろ。
インストール’系’という言葉が気になるが、何かやらかしたの?
windowsで変なソフトを使っていない限り紛れ込むことはない。

862:login:Penguin
08/09/09 04:11:49 W19H5Uqv
>>861
昔酔った勢いでインストール系触ったような・・さわらなかったような・・
多分やってないハズです。
もう一個考えられるとしたら、
バックアップソフトのAcronis True Imageで緊急起動用のブートＣＤ作った時に
作成されたかもしれませんが、うーん・・・

まぁ基本的にはドライブＣ以外のﾃﾞｰﾀはどうなろうが関係ないはずですよね。
ありがとうございます。

863:login:Penguin
08/09/09 09:55:45 IAhfdh01
メーカーPCならリカバリ領域がReiserFSに見えてるのかもしれん・・・
と思ったけど200Mぽっちってことは無いだろうから分からんな。

不安なら1cdLinuxでマウントしてみるとかダンプしてみるとかすればいいんじゃないの？

864:login:Penguin
08/09/09 10:47:10 vqqGOdEY
>>860
板違い。

PC初心者
URLﾘﾝｸ(pc11.2ch.net)

865:login:Penguin
08/09/15 14:01:29 xgMSq0hA
全半角の時点でアレ

866:login:Penguin
08/09/21 07:15:01 oAQntVv0
いま、SSD搭載のノートPCにインストールするとき、お勧めのFSは何でしょうか?
まだ「決定版」は無いみたいですが…

867:login:Penguin
08/09/21 22:36:42 wn9vsd7X
便乗質問ですがSSDってロジカルな意味以外での断片化って
ありうるんですか？

868:login:Penguin
08/09/22 01:22:03 59rWT/4x
あるよ。コントローラが特定チップへの書き込み偏重を起こす副作用があるウェアレベリング手法を採用してたら。

869:login:Penguin
08/09/22 01:22:27 IWoMUFF9
断片化そのものはあるだろうけど、ウェアレベリングで
ランダムなアドレスに書き込んでいるから元から断片化しまくりだろうし、
断片化していてもシーク時間がないから断片化を気にすることに意味がないデバイスだよね。

870:login:Penguin
08/09/22 02:11:58 Ys/3lHk7
>>868,869
オマエらほんとはウェアレベリングのことよく知らないだろw

871:login:Penguin
08/09/22 13:30:45 aeCAnmJw
>>870尊師による具体的かつ詳細なウェアレベリング講座が始まります

872:login:Penguin
08/09/22 17:21:26 gNSkQdpN
講座はいいから、SSDにお勧めのFSを教えてくらさい

873:login:Penguin
08/09/22 17:22:09 6c0BmpVj
btrfs

874:login:Penguin
08/09/22 17:40:04 iwkTRVYz
btrfs はSSD用に開発されたFSじゃないでしょ。

875:login:Penguin
08/09/22 18:42:33 Ed/qK+EY
btrfsって言ってみたかっただけです

876:login:Penguin
08/09/22 21:03:58 iwkTRVYz
理由もなく勧めたわけですか。バカですね？

877:login:Penguin
08/09/22 21:16:43 6c0BmpVj
>>874
すらどに書いてあったから（w

まぁファイルシステムを最適化するよりも、
フラッシュのコントローラの方がこれからまだまだ変わってく
だろうから（今は既存のファイルシステムに合わせて
いろいろ処理を入れている）、当分はファイルシステム側
で何かせずに、ただのランダムアクセスの速いドライブとして
取り扱うのがいいのでは、ということだそうだ。

URLﾘﾝｸ(lwn.net)
KS2008: Filesystem and block layer interaction

878:login:Penguin
08/09/22 21:22:14 RcWgiPXz
iwkTRVYzが執拗につっこむ理由が分からん

879:login:Penguin
08/09/22 22:41:37 ycRdpTD1
nttが作っているファイルシステムとかどうよ。
webページではssdにもおすすめみたいなこと書いてあるけど。

880:login:Penguin
08/09/22 23:28:21 RcWgiPXz
フラッシュ側の書き込み分散がないか下手だと仮定すれば有効じゃない？
その仮定がガンガン変わってるのが現状だけど

881:login:Penguin
08/09/22 23:57:19 ipFxRDfa
原理的に追記型ファイルシステムならSSD（つーかフラッシュ）に
向いているとはいえるな。

ファイルの編集で、元ファイルへの書き込みが同じブロックへの
書き込みになるとウェアレベリングがまったく機能しないが、追記型なら
別のブロックへの書き込みになるから無問題。

ただ、書き込み処理で使う一時領域（ログ領域とか）が常に同じ区画だと、
そこが最初にやられてしまうので、その部分の改善は必要。この問題は
実はHDD時代からあって、XFSでログ領域が先に磨耗する（その領域での
エラーレートが有意に高くなる）という現象がATAプロトコルアナライザで
観測されてたりする。

882:login:Penguin
08/09/23 01:41:25 3BmYbyLb
SSDドライブの耐用年数を増やすカーネルパッチ？
URLﾘﾝｸ(www.atmarkit.co.jp)

883:login:Penguin
08/09/23 12:26:49 TkE/X+T7
>>881
>元ファイルへの書き込みが同じブロックへの
>書き込みになるとウェアレベリングがまったく機能しない

んなことはない。それを散らすのもウェアレベリング。
ただ単に空き領域から領域確保するときにだけ書き替え回数の少ないのを
選択するだけなら簡単だが、それではホントにすぐに壊れてしまう。

884:login:Penguin
08/09/23 13:47:39 7UGRt7NJ
フラッシュのコントローラって
どのアドレスにどんだけ書いたとかの情報も保持してるの？

885:login:Penguin
08/09/23 18:26:10 CdCfBQmf
>>884
ものによるが、普通の安いコントローラはそんな領域はもってないわな

886:login:Penguin
08/09/23 18:31:29 CdCfBQmf
>>882
うむSSDにおいてはdiscard requestが本質で、NILFS, btrfsみたいなappend write思考はウェアレベリング制御コントローラを持たないフラッシュ（組み込み系にしか存在しない）にしか意味がない。
あと、Intelは我が社のSSDのコントローラは超Cooooolなので普通のFSでも全然問題なくて、単に速いHDDとして使えるぜーーって喧伝しているので、カーネルコミュニティ的には、
なんだハードで対策できる問題領域ならハードでやらせたらいいじゃん。的な雰囲気

887:login:Penguin
08/09/23 19:59:58 7UGRt7NJ
>>882
これってさ、つまりSSDに一度fs作った後
全領域をなんかのデータで埋めてしまうと、
それをfs上で削除した後でもdiscardされたことになってないので、
fsのメタデータみたいな書き換えが超頻繁なところでも
フラッシュ上の位置が固定されてしまうってこと？

888:login:Penguin
08/09/24 00:03:41 Qx+obLfG
>>887

flashがいっぱいになっても書き込み位置は固定されない。
固定したらすぐに壊れてしまう。
discardされない場合、fs的には空き領域なのに、不要なデータをコピーして
領域を移動したりすることになるんだろう。
当然コピーすればさらに書き込みが発生するので、その分寿命が縮む。
discardすればコピーしなくてよくなるので、乱暴に言えば寿命が2倍になる。

889:login:Penguin
08/09/24 08:49:33 c9gJjpCf
結局 file system レベルの内容を理解した上で
制御してくれるコントローラが寿命の短い flash memory 向けには
必要なんだけど、実際にはその手前のレベルの実装になってるってことかな?

890:login:Penguin
08/09/24 11:40:33 UINH6EwP
SDカードのfsがFAT16に固定されてたのは
そこら辺が関係してるのかな。
というかSDカードのコントローラってどこにあるんだ？

891:login:Penguin
08/09/24 13:54:37 t2pMdKqe
>>890
そりゃカード側ですがな。

あの手のカードでコントローラが入ってないのは
スマートメディアくらいじゃないかのう。

892:login:Penguin
08/09/24 15:45:17 3ffijfuO
下位レイヤの構造をファイルシステムで考慮するのはあんまり好きじゃないなぁ。
すぐ下層のRAIDストライプ幅考慮くらいならまだ許せるんだけど。
頭の悪いウェアレベリング対策で過渡的にFS側で考慮するのは仕方ないけど、環境に適応しすぎた
進化の先は必ずどん詰まりだし、SSD側で何とかなるなら丸投げする方がいいだろうね

893:login:Penguin
08/09/24 16:15:44 C+IH/2xC
ただ、SSDのコントローラ側は当然ながらFAT32かNTFSしか考えていないわけで。

894:login:Penguin
08/09/24 22:11:45 QRf9ri97
exFATのこともたまには思い出してください

895:login:Penguin
08/09/24 22:43:51 RSAxEbKk
>>893
FATになる部分はどうやってるんだろう

896:login:Penguin
08/09/24 22:49:13 3ffijfuO
>>893
USBフラッシュならともかく、SSDでそれは考えづらい。

SSDはサーバストレージの置き換えも視野に入れてるし、コントローラが特定のFSに
特化するならそれこそ過適応だよ。コントローラがFSに対応してても、RAIDなり
論理ボリュームなりで細切れにされたら全く対応できないわけで。
回路規模でかくして環境依存かつ複雑なアルゴリズムを採用する判断は普通しないだろう。

897:login:Penguin
08/09/24 22:54:40 ZMNTIDGn
最近USBフラッシュ上にインストールできる鳥が多いが、
yum -y update に耐えられるメモリに出会ったことがない。

つか、使えるの教えてほしい。

898:login:Penguin
08/09/24 23:16:14 jpGgbHMv
>>897
yum -y update すると何が起きるの?

899:login:Penguin
08/09/24 23:17:44 YyeaGl1F
USBメモリがパンパンになる

900:login:Penguin
08/09/24 23:27:00 ZMNTIDGn
途中でファイルシステムからI/Oエラーみたいなのが
でるけど、あれは容量が足りてないの？

2GBのメモリで512MBの上書き可能領域を設定していて、
ソフトの２、３個は確かに問題なくインストールできるんだけど。

901:login:Penguin
08/09/24 23:49:03 t6WL9Ml4
大胆に言えば、「未使用部分は消去しないで放っておくという最適化」を止めるというだけ。
その通知はzero fillでは適当ではなくコマンド発行が正しい使い方だったということだよね。

>>897
それは量的な問題で、16GBの奴とか使えばいいんでないか?

902:login:Penguin
08/09/25 09:30:05 gW2/+wNw
>>901

CF ELASE SECTORSだったかな。うろ覚えだけど
結局OSの対応がいるからそのままって訳には行かないしこのコマンド発行してくれる実装のファイルシステムはあるのかしらない。
ZFSあたりはELASE SECTORってのが有った気もするので対応してそうな予感

903:login:Penguin
08/09/26 01:13:27 toU2R+YV
ELASE-SECTOR に一致する情報は見つかりませんでした。

904:login:Penguin
08/09/26 01:48:51 MxRUPN85
>>903

ERASE SECTORやね
スペルミスしてた。ｽﾏｿ

905:login:Penguin
08/09/27 02:44:23 ihJfj8xO
>>900
この件はもっと事例報告があればいいな。
実は自分の所では、もっと高価なSSD (SLC) で似たような事が起きている。
yum upgrade や yum update でバージョンアップしているときに ext3 ナントカ error
(正確なメッセージは記録していない。今度出たらちゃんと記録するよ)
というのが出て、次回起動時に fsckが必要になり、いくつかのファイルが失われた。
(yum upgrade を4回ほどやったうち、2回その現象が起きている)
失われたシステムファイルは yum reinstall で今のところどうにかなっているようではある。

自分のSSDの初期不良なのか、yumなどで大量に書き換えをするときにフラッシュメモリー
デバイスにありうる一般的な問題なのか、切り分けたい所なので、>>900 のような事例が
他にもあれば、報告して欲しいな。

スレ違いなら、どこで訊くのがよいだろう。俺としては、この fs スレで新しい知見が得られると
ウレシイのだけれど。

906:login:Penguin
08/09/27 12:22:06 kG6oXFXC
>>905
USBメモリの容量不足だったようです。すまん。

640MBのイメージが圧縮されているのでOS起動時には
2.1GBのサイズになっているのがdfで確認できる。
つまり約3～4倍に膨れる。

--overlay-size-mb 512 で上書き可能サイズ512MBにしても
ダウンロードパッケージが400MBほど、さらにこれが
展開される領域が必要で、しかももとの圧縮OSイメージ上の
ファイルは消されずそのまま残るので、
ダウンロードパッケージのダウンロード先を別メモリにして、
さらに--overlay-size-mb 1200でも2/3くらい展開したところで
いっぱいになった。

結論 2GB のメモリじゃぜんぜん足りん。orz

907:login:Penguin
08/09/27 20:10:27 GhDIi3T5
つまらんが、安心できる落ちだったなw

908:login:Penguin
08/09/27 20:11:12 GhDIi3T5
おっといけない、報告乙です >>906 。

909:905
08/09/28 04:17:21 yW2sy9CV
安心できないのは俺だけかよ orz
あと1週間もすれば OS の RC1 が出るので、そのときまた yum upgrade で
オカシナことが起きるかも知れん。通常使用では異常は起きてないんだが。

ところで SSD で ext3 を使う場合、書き込みを少しでも減らすために
noatime, nodiratime をマウントオプションに入れるのは有用なのかな。
あるいはこのオプションでファイルシステムを構築すると、動作がおかしく
なるアプリはあるのかな。

910:login:Penguin
08/09/28 05:49:38 VCyQqHEh
noatime,nodiratimeで問題が起こる例に出会ったことは今のところないなぁ
安定重視で運用するなら、まずアップデートが必要かどうかから
検討した方がいいんでない？

911:login:Penguin
08/09/28 19:46:50 ag6sJ/bC
Gentoo とかは noatime 推奨してるぐらいだし大丈夫なんでね?

912:login:Penguin
08/09/28 20:07:30 CeAQTKB8
relatime が導入され理由って、なんだったっけ？

913:login:Penguin
08/09/28 20:59:14 jkHVDhT6
つ man mount

　Similar to noatime, but doesn’t break mutt or other
　applications that need to know if a file has been read
　since the last time it was modified.

本当に "other applications" は存在するのだろうか。
もしかして mutt のためだけに存在するとかありそうだが。

914:905
08/09/29 04:32:31 XZ5p0plM
>>910>安定重視で運用するなら、まずアップデートが必要かどうかから検討した方がいいんでない？
これは耳が痛い。しかし本当に安定重視なら、さっさとSSDを取り替えまーす。

>>911
そうなんですか。ちょっと安心しました。さっそくこのオプションをつけてみました。

>>913
mutt って、メールの未読・既読を atimeで管理しているんですか? だとすればそれはあまり良い仕様
ではないような気がするなあ。

私自身は、大昔に find -atime でファイルを探したりしたこともあったので、無くなると不便かも、
とか思わないでもないですが、ここ10年は -atime なんて使ってないので、まあいいかという気も。

915:login:Penguin
08/09/29 07:33:01 tJYBJ2w6
システムコール lstat で巨大なファイル（5GBとか）の
情報を取得しようとすると、戻り値が -1 で errno には
Errno = 75: Value too large for defined data type
が入って返ってきます。

回避する方法はないものでしょうか？

916:915
08/09/29 08:33:30 tJYBJ2w6
stat64 を使えということは分かりました．
ところでこういう話題はム板の方がいいんでしょうか？
それとも Linux 板でいいんでしょうか？

917:login:Penguin
08/09/29 12:59:49 L4lBHZ6L
>>916
どっちでもロクな回答は返らない
APUE嫁
man嫁
info嫁

918:login:Penguin
08/09/29 13:30:54 cvmxD0my
>>914
メールソフトの場合、ファイルを書くのはsendmail, 読むのはmuttだろ。
んで、特に厳密なプロトコルがあるわけではないので新着お知らせを実装したいと
毎回ファイルを読み直すか、atimeとmtime を比較するか。の話にどうしてもなる気がする。

ローカルにPOPサーバ立てて管理するのが賢いんじゃね？という気もするが。

このへん、メーラ毎に独自ファイルフォーマットのWindowsとは違った苦しみがあるよな。Linux

919:login:Penguin
08/09/29 14:21:27 XZ5p0plM
>>918
しかし atimeとmtime の比較だと、メールリーダー以外のアプリでアクセスすると新着お知らせしてくれなくなるね。

ウチは新着お知らせに asmail を使っているけれど、noatime でもちゃんと「お知らせ」してくれたよ。
less でスプールを読んだくらいでは「お知らせ」は終了しなかった…ってこれは noatime のもとでは当然か。

920:918
08/09/29 23:56:22 cvmxD0my
>>919
ごめん、流れをちゃんと読んでなかった。muttってバカなの？死ぬの？って質問の回答はYes, Of cource. だと思ってます :-)

921:login:Penguin
08/09/30 09:46:51 vrgONqZt
なんかオバカが混じってる気がしますが…
(mutt を使ったわけでも確認したわけでもないでしょ?)

昔ながらの biff とか shell 通知の "you have unread mail"は
>918 が書いてるように mtime, atime 比較をするのが
妥当だしそれしか方法はない
(ただし mbox タイプのスプールにしか使えない手法)

>914 の「未読管理」の話はおそらくその話を誤解している。
mbox だったらスプール全体で時刻情報1つしかないんだから
使用不能だし、maildir 系はそういう情報は使わない
(ファイルに拡張しみたいにつけてく)

>919
それは新しいメールが来た(mtime 更新)の情報でしょ?
上記のlogin時の「まだ読んでないメールあるよ(atimeとmtime)」とは別。
ということでヌケ作は >920 ですね

922:login:Penguin
08/10/01 00:11:34 zZx3s+9c
実は 920=921 と予想。

923:login:Penguin
08/10/01 18:59:06 iSmqobed
root fiesystemにNFSサーバーを使用してボードコンピュータを起動したいのですが
イーサーブート後、nfsマウントしてカーネルはロードした後、
ロード(nfsマウント)したfilesysytemがread-onlyになってしまいます。
/etc/exports下記でrw指定しているんですがなぜでしょうか？

/usr/src/exports 192.168.0.xxx(sync,rw,no_root_squash)

ボードの起動完了後に
mount -n -o remount,rw /
しても効きません

924:login:Penguin
08/10/01 23:31:02 Bd3jk6SU
PXEのコマンドライン晒してみ？

925:login:Penguin
08/10/10 19:11:21 4Novx3gU
UBIFSってなんぞ

926:login:Penguin
08/10/10 19:23:33 ZxeZssLK
>>925
URLﾘﾝｸ(lwn.net)

927:login:Penguin
08/10/10 22:08:17 RWlL9BKf
>>925
フラッシュ用ファイルシステム、ただしＳＳＤのようなコントローラがＨＤＤのフリしてくれるやつには意味ない。
組み込み向けだね

928:login:Penguin
08/10/11 01:12:56 5UHGXJFw
ちょっと前にも話題になっていたけど、SSDにはコントローラの性能向上を信じて
ext3のままでもいいのか、それともフラッシュ向けとされるJFFS2のほうがいいのか
どうなんだろう?

discard patchうんぬんという話もあるしなぁ

929:login:Penguin
08/10/11 03:29:55 C35hQhNl
>>928
SSDには、というか一般のブロックデバイスにはJFFS2やUBIFSは使えないだろ

930:login:Penguin
08/10/11 03:46:56 /DmF+eXK
>>928
面倒な事は何もやらないけど、ものすげー安い or 速いSSD
＋
そういう面倒を引き受けてくれるファイルシステム

つうのがいいんじゃないかと思うんだが、世の中そういう方向に行ってくれなくてのう。

931:login:Penguin
08/10/11 05:03:38 HTsFZd/e
今のファイルシステムも信頼できないのに、どんどんと新しい信頼できそうにない
ファイルシステムをもってくるのはやめてほしい＞Linux。
（客に提案するサーバのうち NFS serverは全部Linux以外だぜHAHAHA!!）

SSDはさっさとECC的なチェック位して、まともにリードエラー出すようにしてくれないと
個人でも心配でメインには使用できない。
ここまで故障しやすいシステムなんてこれまで考慮されてないんだから
ハードウェア側でさっさと対処して、OS標準ファイルシステムがデバイス依存に
ならないようにしてほしいわ。

932:login:Penguin
08/10/11 07:59:47 yGwU5XzZ
>>931
>SSDはさっさとECC的なチェック位して、まともにリードエラー出すようにしてくれないと
もうやってる。
なんでSSDに対して対策が必要なのかを根本的に理解してないタイプか。

933:login:Penguin
08/10/11 08:56:37 ppTdVB+e
直接sambaとかNFSサーバ見せないでプロキシ経由で
アクセスするようにってできないですかね？

直接ファイル鯖いじられたくない困った

934:login:Penguin
08/10/11 09:09:28 QSGYszLu
>>933
よくわからんが、Apache で WebDAV

935:login:Penguin
08/10/11 09:16:02 ppTdVB+e
>>934
sambaとかって
鯖ー鯖(蔵）ー蔵方式で
マウントできますかね？

WebDAVとか遅いからだめなんですよ

936:login:Penguin
08/10/11 09:24:39 WkhcPGyl
>>935
質問の仕方もおかしいし、スレ違いって事もわからないようじゃ君には無理。

937:login:Penguin
08/10/11 11:49:16 /eNXCR9B
>>931
LinuxのFSが信頼性よりパフォーマンスなのは同意するが
NFSサーバがLinuxじゃないのはNFSが互換実装なのを嫌った方がでかいだろう。

SSDでも突っ込み入っているけど、調べる癖は付けといたた方がいいよ。
客とやらを不幸にする前にね。

938:login:Penguin
08/10/11 12:39:21 F5yk1I08
>>931
おまえがタームだけしか知らずにモノを言うシッタカなのは理解してあげたので、
とりあえず
URLﾘﾝｸ(homepage3.nifty.com)
でも読んで出直せ。

939:login:Penguin
08/10/11 14:10:29 g3joq6C9
SSDがどんどんHDD的に使えるようになってるのでFS開発者としては
新設計なしで静観予定らしいけど、

　SSD,HDD -> 従来FSでおけ
　生フラッシュ -> MTD, UBIでおけ
　USBメモリとか -> 選択肢が無い・・・

というわけで、大容量USBメモリとかSD/CFが使いにくいまま。

小容量ならinitramfsでメモリ展開して終わりなんだけど、
大容量フラッシュメモリデバイスをうまく使う方法が無いのが
ちょっと微妙。tmpfsを被せて使うくらいしかできない。

940:login:Penguin
08/10/11 14:14:16 ZEc5lvl1
NTFSでハードリンクを使ったら、削除がすごく遅くて使えない
というか、１つの実体ファイルに対してのハードリンクの数に
比例して速度が落ちていっているようです。

pdumpfsで10万ファイルくらいあるフォルダをバックアップして
３ヶ月くらい放置してあったんだけど、
（実体が約10万ファイルで、×90日＝約900万個のハードリンク）

pdumpfs-cleanがいつまで経っても終わらないので調べてみたら
上の状態で１日分削除するのに１時間以上かかっていました。
ハードリンク数が減ってくればスピードが上がるとはいえ、これでは
クリーンアップが終わる前に、次のバックアップ時間になってしまいます。

ext3とかXFSでもこんなに遅い…なんてことはないですよね？
バックアップ専用にLinuxサーバーを作ろうとか考えてるけど。

941:login:Penguin
08/10/11 14:35:59 3CVcp8Gk
>>940
バックアップ先にネイティブではないFSを選択するなんてどうかしている。

942:login:Penguin
08/10/11 16:31:14 ZEc5lvl1
>>941
Windows上でNTFSを使っているからファイルシステムはネイティブですよ。
LinuxのNTFS実装ではなくて、Windowsから直に使っても劇遅なのです。

pdumpfsはWindows用の実装もあって、Windows用はNTFSのハードリンクを使う。
元々pdumpfs自体はLinux上で使うように作られていたので、
Windows移植版は亜流扱いかなと思って、本来の環境(Linux+ext3/XFS)での
バックアップ運用を考えているんだけど、こっちでも同じようにパフォーマンスが
落ちるなら新しくサーバーを作る意味がないのです。

ext3ならハードリンクの削除はi-nodeの削除と参照カウントを変更するだけだと
思うのでパフォーマンスは落ちない気はするのですが、実際はどうなのかなと。

943:login:Penguin
08/10/11 17:05:54 F5yk1I08
>>939
SDなんて規格でSDだとFAT、SDHCだとFAT32を使うことを決められているんだし、
CFやUSBメモリもFSの規格化こそされていないものの、既存のFAT32から変更する
ことなんて相互運用性を考えるとありえないし、FSレベルではできることは
FAT32でwrite buffer回りをフラッシュ向けのパラメータに調整するとか、
かなり限られるだろうからなぁ。

運用面では、いったんHDDなりtmpfsなりに書き出してから、カードを抜く前に
一気に書き出すようにするとか、fsだけでやるよりは、いろいろやれるだろうけど。

944:login:Penguin
08/10/11 21:38:02 g3joq6C9
>>942
そう考えるとVistaのReadyBoostはうまいよな。
HDDよりはるかに高速なリード系キャッシュとしてのみ使って、
ライトはキャッシュしないでHDDにダイレクトに戻すわけだから。
OS側でHDD+Flashのハイブリッドデバイスにしてるようなもん。

Linuxでもaufsとかでうまくラップしたら同じ構成にできるかな？

945:login:Penguin
08/10/11 22:33:13 BChDsKTE
>>944
今ならRAMを大量に積んで、開いたRAMを積極的にキャッシュに使うほうが
有意義だと思うが、RAMよりはるかに低速なFlashを使う意味はあるのか？

946:login:Penguin
08/10/11 22:35:35 3CVcp8Gk
VistaのReadyBoost は思ったほど効果が出ないので廃れてきている。
メモリいっぱい積んでキャッシュした方が速い。

947:login:Penguin
08/10/11 22:39:15 /eNXCR9B
>>945
アイドル時の消費電力

948:login:Penguin
08/10/11 22:51:43 g3joq6C9
>>945
VMwareが使うテンポラリ領域に今はtmpfs割り当ててるけど
メモリ圧迫がきつい。なので、RAMより遅いけどHDDよりはランダム
リードが速いフラッシュに持っていきたい。

でも、いまだとリードキャッシュにのみ使うというような使い分けが
できないのでUSBフラッシュの激遅なランダムライトが思い切り足を
引っ張ってしまう。なので泣く泣くtmpfs使ってる。

949:login:Penguin
08/10/11 23:30:52 BChDsKTE
もちろん環境によって違うが、VMwareならメモリ8GBもあれば
ほとんどオンキャッシュじゃないか？

950:login:Penguin
08/10/12 15:34:42 cHEoGiGP
>>939
USBメモリもＯＳから見たらＡＴＡだ

>>943
おかげで、ＦＡＴ前提で消去動作をするデバイスがいて困る

951:login:Penguin
08/10/12 16:17:22 caxeqjv+
>>929
普通のブロックデバイスでJFFS2を使う方法は、ある

952:login:Penguin
08/10/12 23:38:54 cHEoGiGP
>>951
方法はあるがJFFS2のメリットがまるで生かせないのでオススメはしない。

そもそも、ブロックデバイス経由となるとそれなりに大きなフラッシュが大半だが、
JFFS2は大容量にあまりうまくスケールしない。

953:login:Penguin
08/10/13 03:50:43 /1X8bqTg
>>950
SCSIじゃないの？

954:login:Penguin
08/10/13 05:54:18 Yen7BMcS
>>950
USB mass storage classの立場が…

955:login:Penguin
08/10/13 10:31:00 KYd3m3EJ
>>942
WindowsのNTFS上のファイルをNTFS以外のところに
バックアップするのを>>941は言ってるんじゃないの？

956:login:Penguin
08/10/13 11:56:43 gw7EyGVh
ディスクイメージを丸ごと保存するしか無いことに気付くのさ

957:login:Penguin
08/10/13 16:17:01 0i0p6LYA
結局 dd とか Acronis TrueImage に頼らざるを得ないよな

958:login:Penguin
08/10/19 09:56:52 Y5v4Sc4N
Kernel Log: Ext4 completes development phase as interim step to btrfs
URLﾘﾝｸ(www.heise-online.co.uk)

959:login:Penguin
08/10/19 13:51:01 UH6RFsrQ
btrfsってベターエフエスじゃなくてバターエフエスだったのね

960:login:Penguin
08/10/20 16:30:26 kMVayZDo
NTFS並みにぶっ壊れないNTFS以外のFSないー？？？

961:login:Penguin
08/10/20 16:37:15 iP5zKBzc
>>960
おい、しっかりしろ！
壊れてるのはファイルシステムじゃなくてオマエの頭だ！

962:login:Penguin
08/10/22 08:49:29 I6jwpH/K
NTFS並みに「ぶっ壊れない」NTFS以外のFSないー？？？
じゃなく
「NTFS並みにぶっ壊れ」ないNTFS以外のFSないー？？？
じゃね

963:login:Penguin
08/10/22 10:59:57 NBHzzMxf
みなさまお勧めのFSはなんですか？(2008/10現在)

964:login:Penguin
08/10/22 14:12:28 C4w3eGpm
>>963
ヴぁたーえすえふ

965:login:Penguin
08/10/22 14:12:49 jdRhwaU9
JFS
もっとも中庸

966:login:Penguin
08/10/22 14:42:09 C4w3eGpm
JFSって実用に耐えるような品質じゃなかったような

967:login:Penguin
08/10/22 14:53:47 gVMTbwAJ
NTFS壊れないだろ。あれだけ利用者がいることを考えたら驚異の堅牢さ。

968:login:Penguin
08/10/22 14:55:10 q1aPF8u5
>>967
その点は認めるが、その分安全性に振ってあるせいか遅いんだよね。

969:533
08/10/22 20:05:03 pEgnaN2Y
>>966
個人レベルじゃ分からんね
まだファイルシステムとして問題になったことはないね。

970:login:Penguin
08/10/22 23:25:49 Df2ywAsR
ZFS(`･ω･)

971:login:Penguin
08/10/22 23:27:19 C4w3eGpm
>>969
壊れるわ落っこちるわで
個人レベルで使い物にならなかったから言ったんだが

972:login:Penguin
08/10/22 23:54:29 jdRhwaU9
JFSじゃなくて個人の能力の問題ぽいな

973:login:Penguin
08/10/22 23:58:54 1b7uzJ+6
能力者か

974:login:Penguin
08/10/23 01:03:22 AE+LtDQB
JFSの評価は試した時期によって真っ二つに分かれるよ。
オレはダメダメな頃に試して、開発チームの品質意識の低さに愛想が尽きたクチ。あんなものをv1.0とかリリース版とか呼ばないでくれ・・・

まあそろそろ許してやるかと思わんでもないけど、最悪レベルの悪印象１回で５年は忌避するね。

975:login:Penguin
08/10/23 01:19:26 NIVvYMeo
俺は一昨年あたりに試して駄目だったがな
どこかで「JFSは性能は悪いが安定してる」みたいなのを読んで騙された
三台くらいのマシンで使ってたが愛想が尽きたよ
Squidのキャッシュにしたらカーネルが頻繁にこけるし
数十GBのファイルシステムに使ったら1月も経たないうちに壊れやがった
全面的にxfsに切り替えてからはノートラブル

976:login:Penguin
08/10/23 01:43:33 rce9rSrQ
さすがに嘘っぽいなw

977:login:Penguin
08/10/23 01:53:17 h1GjsnzS
普通にufs(ffs)でいいと思うんだが。
だめっすか?

ちなみに、NTFSはVista SP1/W2K8 からNTFS Transactionが
入ったのがｽｹﾞｰよ。UNIXのFSには同じ機能はないよねえ。

978:login:Penguin
08/10/23 04:20:41 AeDLf20b
ufsとかほとんど使われてないだろ。

transactionは確かにあれば便利なような気はする。
でも実装するとなるとそうとうにvfsの大改造が必要になりそう…。

979:login:Penguin
08/10/23 06:49:03 AE+LtDQB
reiser4に入る予定だったのに・・・

980:login:Penguin
08/10/23 11:58:13 psJByFA2
>>975
ほおー。

以前も書いたかもしれないけど、俺はフェイルオーバークラスタ
の共有ディスクにして、httpdのドキュメント＆ログ兼postgresの
DB置き場にしていたけど、特に問題は起きなかったけどなぁ。

共有ディスクなんで、オンラインでのマウント・アンマウントなんか
も発生したけど、ファイルシステムの異常は発生しなかったよ。

981:login:Penguin
08/10/23 14:22:40 NIVvYMeo
>>980
それってappendと、既に割り当て済みの領域への書き込みしか発生しないだろ
ファイルシステムのテストになってないぞ

982:login:Penguin
08/10/23 20:49:02 xBWodj0l
>>970
ZFSってFUSEで実装してる分のオーバーヘッドってどんなものなんでしょうか？

983:login:Penguin
08/10/23 20:50:42 psJByFA2
>>981
別にファイルシステムのテストを企図して使ってたわけじゃないが、
頻繁にWebコンテンツの追加・削除は発生してたし、ファイルの
アップロードも存在したし、とあるシステム向けのデータファイルが
日ごとに追加されてたんで、それなりに負荷はあったと思うよ。

984:login:Penguin
08/10/23 21:25:23 IxMIJ6A4
とはいえ、やっぱりある程度特殊な環境かと。
webコンテンツの更新やらファイルのアップデートなんて、いくら頻繁でも
たかが知れている。

共有は共有でも開発環境のファイルサーバで、しょっちゅう
makeが動くとかなら話は全然別だけど。

985:login:Penguin
08/10/23 23:31:32 sA6CnTJk
ウチは、今年前半にメールサーバ、Webサーバのデータ領域として導入。
533にあるとおり、PPC Ubuntuで。
メールは、IMAP管理で基本的にスパムも削除しないで単純増加がほとんどかな？
あと、ファイル管理のスワップファイルをおいている。スワップはあまり使われてない。

とりあえずjfsだからってことで困ったことはない感じかな？

986:login:Penguin
08/10/24 00:50:46 BMCuftSP
データベース以外の用途なら、やっぱZFSがいいよなぁ。