11/07/28 09:15:02.49 jvQGhVpc
●前スレ
ファイルシステム総合スレ その12
ｽﾚﾘﾝｸ(linux板)
●関連スレ？
OpenSolaris/Illumos (OpenIndiana, etc.) 5
ｽﾚﾘﾝｸ(unix板)
過去スレ、関連リンクは >>2-10 あたりで。
2: 忍法帖【Lv=22,xxxPT】
11/07/28 09:15:52.85 jvQGhVpc
●過去スレ
01 ｽﾚﾘﾝｸ(linux板)
02 ｽﾚﾘﾝｸ(linux板)
03 ｽﾚﾘﾝｸ(linux板)
04 ｽﾚﾘﾝｸ(linux板)
05 ｽﾚﾘﾝｸ(linux板)
06 ｽﾚﾘﾝｸ(linux板)
07 ｽﾚﾘﾝｸ(linux板)
08 ｽﾚﾘﾝｸ(linux板)
09 ｽﾚﾘﾝｸ(linux板)
10 ｽﾚﾘﾝｸ(linux板)
11 ｽﾚﾘﾝｸ(linux板)
12 ｽﾚﾘﾝｸ(linux板)
●関連リンク
ext4 URLﾘﾝｸ(www.bullopensource.org)
reiserfs/reiser4 URLﾘﾝｸ(www.namesys.com)
xfs URLﾘﾝｸ(oss.sgi.com)
jfs URLﾘﾝｸ(jfs.sourceforge.net)
nfs URLﾘﾝｸ(nfs.sourceforge.net)
ntfs URLﾘﾝｸ(www.linux-ntfs.org)
fuse URLﾘﾝｸ(fuse.sourceforge.net)
btrfs URLﾘﾝｸ(btrfs.wiki.kernel.org)
NILFS2 (NTT) URLﾘﾝｸ(www.nilfs.org)
3: 忍法帖【Lv=22,xxxPT】
11/07/28 09:16:21.97 jvQGhVpc
●関連リンク2
en:List of file systems
URLﾘﾝｸ(en.wikipedia.org)
Linuxファイルシステム技術解説
URLﾘﾝｸ(www.atmarkit.co.jp)
File Systems in Linux
URLﾘﾝｸ(www.linux.org)
Linuxの次世代ファイルシステムは「バターFS」!?
URLﾘﾝｸ(www.atmarkit.co.jp)
Linux ジャーナリング・ファイルシステムの徹底調査
URLﾘﾝｸ(www.ibm.com)
Linux フラッシュ・ファイルシステムの徹底調査
URLﾘﾝｸ(www.ibm.com)
Linux filesystem benchmark 2008/1-2
URLﾘﾝｸ(www.t2-project.org)
URLﾘﾝｸ(www.t2-project.org)
Filesystem Specifications - Links & Whitepapers
URLﾘﾝｸ(www.forensics.nl)
Linuxファイルシステムベンチマーク ext3,ext4,JFS,ReiserFS,XFS,NILFS2
URLﾘﾝｸ(plaza18.mbn.or.jp)
URLﾘﾝｸ(plaza18.mbn.or.jp)
[Phoronix] Benchmarking ZFS On FreeBSD vs. EXT4 & Btrfs On Linux
URLﾘﾝｸ(www.phoronix.com)
こんなもんか。不足・情報古すぎ・新情報ありましたら訂正よろしく。
4:login:Penguin
11/07/28 09:58:33.44 GfkxXlQR
FUSE最強伝説
●curlftpfs
FTP鯖のディレクトリをマウントできる。
●sshfs
sshのしゃべれる鯖のディレクトリをマウントできる。
●mhddfs
複数のディレクトリを結合して大きなディレクトリに見せかける事ができる。
RAID0やJBODよりも耐障害性が高い。
●lessfs
重複ファイル統合・圧縮・暗号化を行ってくれる出来杉君。
5:login:Penguin
11/07/28 10:11:53.28 FYNTyx/o
まあ、「伝説」なんて都合よく曲解されて伝承される訳で
6:login:Penguin
11/07/28 21:12:17.34 9X016Sem
●関連スレ
ジャーナリングファイルシステム
ｽﾚﾘﾝｸ(unix板)
7:login:Penguin
11/07/29 00:30:27.30 cxhLsxrY
●関連リンク2 のリンク切れ修正
Linuxファイルシステムベンチマーク ext3,ext4,JFS,ReiserFS,XFS,NILFS2
URLﾘﾝｸ(hesonogoma.com)
URLﾘﾝｸ(hesonogoma.com)
8:login:Penguin
11/07/29 00:37:31.18 y8fMPdKa
>>5
reiserfsですね。わかります。
9:login:Penguin
11/07/29 00:59:29.79 5sqBqGKJ
(｀・ω・´)ゞ 乙であります！
#最近のIMEはおつだけで凄い変換掛かるんだな
10:login:Penguin
11/07/29 16:13:50.19 6ISwKpe2
Windowsでfuseみたいなのがあるって聞きましたが、どんな名前でしたっけ
11:login:Penguin
11/07/29 16:38:52.27 nZBjVfYh
Windows の話は別の板で聞いた方がいいんじゃないすか。
12:login:Penguin
11/07/29 17:29:21.38 6ISwKpe2
例えばどこで？
13:login:Penguin
11/07/29 17:31:09.61 nZBjVfYh
さぁ。
14:login:Penguin
11/07/29 17:33:49.95 gdmEEZkF
昔、WindowsでExt3を読みたかった時にググったらソレらしいＨＰが見つかった事があった
ような、なかったような・・・スマン
15:login:Penguin
11/07/29 17:56:00.00 s89xLVSr
URLﾘﾝｸ(dokan-dev.net)
これのことかな
現時点ではFUSEとはAPIの互換性はないけど将来的にはwrapperを用意するらしい
16:login:Penguin
11/07/29 21:56:19.82 U+Os21A/
>>10
Dokanだね。
イマイチよ。
17:login:Penguin
11/07/30 00:27:00.58 /CIxnH1Z
>>10
つ Dokan
18:login:Penguin
11/07/30 03:13:07.08 zXsfstkX
識者の方おながいします
rsync で双方のデータコピーを検討しているのですが
一方のファイルシステムがext3、もう一方がext4という状態なのですが
これって問題あるでしょうか
また同じように32bit OSと64bit OSの場合って問題あるでしょうか
19:login:Penguin
11/07/30 04:31:18.57 +Gq74S4b
>>18
ext4とNILFSでrsyncしましたが、何も問題ないように見えましたよ。
実際、何を心配されてるんでしょうか？
20:login:Penguin
11/07/30 07:36:44.72 tWXAiRc1
>>18
合ったら困ると思いますが、実際、何を心配されてるんでしょうか？
21:login:Penguin
11/07/30 08:39:32.34 oS9ms+L2
>>18
それで問題が出ないのが linux というか vm の偉いところ。
32bitと64bitって、x86とx86_64だよな? エンディアン違ったりしないよな?
22:login:Penguin
11/07/30 11:42:37.00 tWXAiRc1
>>21
＞それで問題が出ないのが linux というか vm の偉いところ。
VFSのことか？
23:18
11/07/30 11:44:15.42 zXsfstkX
>>19-21
レスありがとうございます。
> 32bitと64bitって、x86とx86_64だよな? エンディアン違ったりしないよな?
すいません、おっしゃるとおり、x86とx86_64 です。
エンディアンという言葉は具具ってもイマイチ理解できませんでしたorz
バックアップ用途を目的としているので
いざバックアップを使うときに何かファイルのずれがあったら困るな、
と漠然と不安に感じたのが質問させていただいた理由です。
rsyncって双方にそれぞれインストールして使うものなので
それぞれの根本的な環境（ファイルシステムやx86,x86_64）が
異なると何か問題起きないかなと。
24:login:Penguin
11/07/30 11:49:11.86 tWXAiRc1
>>23
拡張属性は吹っ飛ぶかもしれないけど、大丈夫だよ。
25:login:Penguin
11/07/30 17:58:40.36 ILbAI85o
>>21
>32bitと64bitって、x86とx86_64だよな? エンディアン違ったりしないよな?
お前何いってんだ？
26:login:Penguin
11/07/30 18:10:28.75 Hf+wXwZj
rsyncでエンディアンとかbit長とかfsとか気にしたことないのう
そーいえば32bit環境のsqliteで作ったdbを64bit環境に持って行ったら読めねえ
みたいな話を聞いたことがあるような
27:login:Penguin
11/07/30 18:14:12.53 lYfHe8x7
誰かマジレスおねがいね
28:login:Penguin
11/07/30 18:33:48.45 yBO488L7
smbでもnfsでもいいからマウントして、rsyncしときなはれ。
29:login:Penguin
11/07/30 20:09:51.07 e038gY+5
>>28
そんな非効率なことできません
転送量に応じて課金されるので
30:login:Penguin
11/07/30 21:22:35.51 yBO488L7
だったら、転送すんな。
31:login:Penguin
11/07/31 00:37:26.79 W1vjp2N3
そっか、テレホタイムに転送すればいいんだ
rsyncって、テレホ時間内に転送を終わらすオプションとかありますかね
32:login:Penguin
11/07/31 01:29:06.35 /TNnPkfz
ISDNなんか?
33:login:Penguin
11/07/31 03:20:44.89 uF6StV0A
テレホタイムとか、15年前くらいから来た人かよ。
そんなオプションあるわけねーだろｗ
34:login:Penguin
11/07/31 07:53:27.76 8k4I4G6c
テレホーダイ自体はあるだろ
35:login:Penguin
11/07/31 20:25:21.36 rVj6LoVI
ネット定額制は終わるらしいし
テレホ復活はありえなくもない
って何のスレだよ
36:login:Penguin
11/07/31 23:04:46.21 +FnLWd82
次のお題: テレホ時代のファイルシステム
37:login:Penguin
11/08/01 00:10:00.84 62a92VwI
cronで
23:05 wget起動
07:55 wgetをkill
で何日かかけてisoイメージを落とした
フレッツ出来て速度半分の代わりに時間制限なくなって嬉しかったのう
38:login:Penguin
11/08/01 00:12:03.28 RFUTP44j
すげえなww
執念だわ
39: 忍法帖【Lv=23,xxxPT】
11/08/01 09:32:18.32 /B4YGscF
1週間かけてCDイメージ3枚落としたら、1枚MD5が合わなかった時の絶望感
40:login:Penguin
11/08/01 14:43:54.01 eq3+JgN2
torrent使え
41:login:Penguin
11/08/01 16:31:54.51 4SBrQ+Oh
torrentって、普通にftpで用意されてるファイルの転送にも使えるんだ。
知らなかった
42:login:Penguin
11/08/01 17:02:17.20 U9HiT23K
>>39
そしてrm後に見てたのが
改行したSHA512だと気付く
43:login:Penguin
11/08/01 21:16:02.43 YNSsgp/O
アナログやISDNの時代にtorrentやSHA512が普通に使われてたのか
44:規制の為分割(1/2)
11/08/01 21:44:07.51 /hoUnSpd
3～4台で冗長化されたボリュームをいくつか寄せ集めて一つのディレクトリに
見せかけつつ、万一ボリュームのどれかが破損しても他のボリュームには
波及しないようなファイルシステムを探しています。
例としてZFSを単純に書き込みホール問題が対策されていて、パフォーマンスが
そこそこ高い(CPU使用効率が高い)ソフトRAIDの代替FSとして使いたいのですが
ZFS＋mhddfsが使える環境というものはありますでしょうか？
45:規制の為分割(2/2)
11/08/01 21:46:19.18 /hoUnSpd
FreeBSDだとZFS+UnionFSで同じようなことは出来そうなのですが
UnionFSだと、mhddfsで提供される以下の機能
・単一のファイルが複数のディレクトリを跨ぐようには書き込まれない
・空き容量内に収まるファイルの場合、隙間に埋まる様に書き込む
が使えるのかどうかわかりませんでした。
46:login:Penguin
11/08/01 22:48:21.02 fU3LTHwj
普通にRAID-10じゃダメですか？
47:login:Penguin
11/08/01 23:00:30.34 mzmQRPsp
>>31
rsync -teleho
48:login:Penguin
11/08/02 00:46:14.88 EGyT4XN5
>>44>>45
LinuxでZFS FUSEが安直な答えかな。FUSEとmhddfsの相性は知らんし、遅いけど。
それか絶賛開発中のZFS on Linuxか。
しかしなんで冗長化したボリュームの破損を心配するのかがわからん。
ボリューム丸ごと飛ぶときなんて、大抵他のボリュームまで含めて全部飛ぶような事故なんじゃないのか？？
49:login:Penguin
11/08/02 00:57:17.94 WA1kisMP
>>48
そんなどこかの原発みたいなこと言わないで下さい。
100%の安全を求めているんです。
50:login:Penguin
11/08/02 01:01:50.54 BGHsnk3H
じゃあ今すぐ電源切って回線吊って寝ろ
51:login:Penguin
11/08/02 01:16:39.11 EGyT4XN5
>>49
そんなどこかの原発反対派みたいなこと言わないで下さい。
100%安全なファイルシステムやHDDなんて存在しません。
こうですかわかりません＞＜
52:login:Penguin
11/08/02 05:52:55.09 cZDemRyV
結局障害発生時に焦って、
正常なドライブを交換してしまい、何もかもが台無しになる可能性も
考えた方がいいよ。
どこかの原発ってそう言う感じだったじゃん。
53:login:Penguin
11/08/02 08:55:42.31 LgRQFoIf
>>49
HDD4つでRAID-1でもしとれ。
54:login:Penguin
11/08/02 09:20:26.31 VUU4JVsF
え？
4つでRaid-1って出来るの？
Raid1構成が2つではなくて？
55:login:Penguin
11/08/02 09:32:11.89 Rw3NRAkL
>>54
RAIDの概念もう一度勉強してこい
56:login:Penguin
11/08/02 09:39:42.25 VUU4JVsF
>>55
概念が分かってらっしゃるなら、
>>53に対する意図ってのも分かってくださいよ
すぐ薄識をひけらかす阿呆が現れるんだもんなぁ
57:login:Penguin
11/08/02 09:53:12.36 seNP102N
悪態をつかないと気がすまないってのもいかがなものかと。
58:login:Penguin
11/08/02 10:03:07.47 xfEjCrhl
HDD2のRAID1で1つ逝くと再構築中に大丈夫だったのが飛ぶと死ぬけど
HDD3つ以上でRAID1だと再構築中にさらにもう1つ死んだとしても大丈夫だろ？
そしてまともなコントローラーだと負荷分散かストライピング読みするから
パフォーマンスも上がる
59:login:Penguin
11/08/02 10:05:53.54 Rw3NRAkL
>>56
一回首釣ってこい 夏休み野郎
60:login:Penguin
11/08/02 10:36:20.33 BGHsnk3H
まてまて、ずっと夏休みかもしれんぞ
61:login:Penguin
11/08/02 10:44:12.69 OFqoaRVK
>>54
実装によってはできるよ。
URLﾘﾝｸ(download.oracle.com)
62:login:Penguin
11/08/02 10:51:05.57 Rw3NRAkL
>>60
それは考えもしなかった
63:login:Penguin
11/08/02 13:36:42.57 ggJjIJyV
zfsでraidz プール運用中ですが、昨晩の地震から、raidz リシルバ中に地震来たらと思うと眠れなくなってしまいました。
地震を考慮しているRAIDはいくつになるんでしょうか。
64:login:Penguin
11/08/02 13:43:19.41 OFqoaRVK
そういうのは RAID じゃなく
定期的に別メディアにバックアップとった方がいいんじゃね?
65:login:Penguin
11/08/02 13:51:05.84 rHJjxeot
いやいや、別地域または他国じゃないと一緒に
66:login:Penguin
11/08/02 13:53:44.93 OFqoaRVK
そこまでコストかけるかは難しいでしょ。
テープなり DVD なりなら HDD みたいにクラッシュすることはない。
埋まったり燃えたりはするかもしれないけど。
67:login:Penguin
11/08/02 13:55:30.18 BGHsnk3H
terastationを沖縄に・・・
68:login:Penguin
11/08/02 14:34:52.34 J1thccXF
沖縄だけじゃ足りん。
10km級の隕石衝突時の津波にも耐えられるよう、
ヒマラヤとアンデスにも置いておくべき。
69:login:Penguin
11/08/02 15:04:53.58 EGyT4XN5
各地にRAID5で組んだSANを設置して、iSCSIなりでマウントしてミラーリングすれば？ｗ
70:login:Penguin
11/08/02 16:11:59.45 SXqV3mPc
それなんてP2P?
71:login:Penguin
11/08/02 17:07:30.92 xfEjCrhl
今のトレンドは月にSAN
72:login:Penguin
11/08/02 20:00:53.89 ogzVFJ5o
這い寄る障害
73:44-45規制の為分割(1/2)
11/08/02 23:21:17.75 4ND6FVsu
>>48
レスありがとうございます。ことLinux環境だと、やはりそういう選択肢になりますかね。
なぜ冗長化しておきながらunion mountをしたいのかとういう点ですが、ミラーや
ダブルパリティは容量単価的に苦しいのでシングルパリティを考えています。
そのため冗長化としてはやや貧弱な事、また自身のオペレートミスの可能性も
重々考えられるため、RAIDのみの単一冗長化ではなく多少のファイル損失の
リスクはあっても、一部のディスクアレイ障害が全体に波及しない構成を検討した結果です。
74:44-45規制の為分割(2/2)
11/08/02 23:23:35.83 4ND6FVsu
FreeNASをセットアップしてGUI設定画面をざっと見まわしましたが、ZFSは
提供されていても、mhddfsやUnionFSは提供されていないようですね。
FreeBSDであればUnionFSは提供されていると思いますが、OpenIndianaでも同様でしょうか？
・Linux (ZFS FUSE+mhddfs)
・FreeBSD (ZFS+UnionFS)
のいずれかの構成が有力だと思いますが、現行のUnionFSはmhddfsや
Another Unionfsと比べて遜色ないのかも気になります。
どなたかご存じないでしょうか？
75:login:Penguin
11/08/03 22:54:03.49 nuFd+4gm
>>74
そもそもunionfsとmhddfsを同一視してる時点でドン引き。
76:login:Penguin
11/08/03 23:04:24.71 5wiKIPAa
>>54
実家にあるサーバを HDD5台で raid1 してる俺が通りますよ。
障害時に起動ディスクが中途半端に死んで起動しなかったぜ。
77:login:Penguin
11/08/03 23:06:29.74 5wiKIPAa
>>73
俺も色々考えたが、結局ミラーリング+定期バックアップが一番だぜ。
78:login:Penguin
11/08/03 23:08:29.29 tHTLaUVw
マシンを２重化するだけでおk
79:login:Penguin
11/08/03 23:22:17.57 w+601lcf
>>73
RAID5ボリュームを2個連結するならRAID6ボリューム1個でも容量単価変わらないじゃん。もっと繋ぐなら尚更。
RAID50よりRAID6の方が冗長性高いわけだし、オペレートミスなんて懸念してたら何もできないだろ。
あるRAID5ボリュームがデグレードしたときに間違って違うRAID5ボリューム操作しちゃうことだって考えられるわけだろ？
やろうとしてることの意味がまったく理解できないから何を答えていいかもわからん。
80:login:Penguin
11/08/04 02:42:24.63 VDz3tOBv
オペレートミス対策ならNILFS一択ですね
81:73-74
11/08/04 06:52:12.58 7ZWwsDmO
>>79
＞やろうとしてることの意味がまったく理解できないから何を答えていいかもわからん。
でしたら、UnionFS, mhddfs, aufsの違いを教えてください。お願いします。
82:login:Penguin
11/08/04 22:57:04.02 /iteUJIa
>>81
無意味にしか感じられない作業をするための質問に答えられることなんてないって言われてんだよ。
「穴を掘ってその穴を掘り出した土で埋めたいんですが、スコップとシャベルの違いを教えてください」
って言ってるのと同じ。意味のない目的のためにどの手段が優れているかなんて解答は存在しない。
83:login:Penguin
11/08/04 23:24:58.22 ihNAdisP
FATさいでりあ～
84:login:Penguin
11/08/05 00:46:23.47 zr5LhcIu
来月予定のFreeBSD 9はZFS v28搭載か
ファイルサーバー用に試してみるかな
85:login:Penguin
11/08/05 02:06:41.81 T9t62qzT
exFAT完成まだ？
86:login:Penguin
11/08/05 11:59:12.36 Mv9R3ziI
v28 試すだけなら MFC 後の 8STABLE の方がトラブルなさそうだ. 新インストーラわけわかんなかった
87:login:Penguin
11/08/05 15:33:46.57 TrhDnRsN
電源を突然切っても整合がとれるってどうやってるの？
論理的な部分だけじゃ実現出来ないと思うんだけど。
88:login:Penguin
11/08/05 18:48:29.02 sAeP0z/0
レスする前にまずググれ
89:73-74
11/08/05 23:29:25.45 pMdacqa1
>>82
ですからUnionFS, mhddfs, aufsの違いについて教えていただければ結構です。
それぞれの優劣についてまで求めていません。
90:login:Penguin
11/08/06 00:24:10.03 TEafOsk6
>>89
少なくとも名前は違いますね。
91:login:Penguin
11/08/06 11:44:28.41 bs9v5y3O
>>89
お前には絶対に教えてやらん。絶対ニダ。
92:login:Penguin
11/08/06 21:38:03.08 Yx8//JY3
俺もFS作ってみるかな。
次世代っぽくて、カッコイイ名前から考えるか。
93:login:Penguin
11/08/06 21:43:56.37 q7pvPo2d
>>92
エロ画像を自動で隠してくれるFSｷﾎﾞﾝ
94:login:Penguin
11/08/06 22:37:47.93 hsXUlVRZ
>>92
New Technology FS
>>93
YomeFS
95:login:Penguin
11/08/06 22:43:35.18 HYl/z1i2
>>94
YomeFSだとエロ画像を自動的に削除＋お叱りが来るじゃないかw
だからこう言うファイルシステムを希望しているんだ
kYomeFS
96:login:Penguin
11/08/07 00:53:00.06 D1sV4Ek8
>>95
空気嫁? w
97:login:Penguin
11/08/07 20:54:23.95 nx2cZW0s
MamanFS
美味しそうなご飯の画像を勝手に拾ってきてくれる。
BitchFS
ブランドもののバッグと諭吉の画像しか受け付けない。
98:login:Penguin
11/08/07 21:25:03.65 XxXxKDbV
SCSI経由のIDEのHDDドライブを
mkfs.ntfsコマンドでNTFSでフォーマットしてたら
１００％まで言ってルートディレクトリがなんとかってエラーが5つくらいでて
その後、HDD自体認識しなくなったんだけどもしかして、もうだめ？
99:login:Penguin
11/08/07 21:58:39.48 acXf9qm6
BIOSで認識してるの？
100:login:Penguin
11/08/07 22:44:54.08 XxXxKDbV
だめっぽい>>99
101:login:Penguin
11/08/07 22:51:16.59 LNn8pLV+
>>100
lsscsiは？
102:login:Penguin
11/08/07 23:18:25.01 acXf9qm6
そりゃ、逝ったんじゃね
103:login:Penguin
11/08/07 23:20:32.34 RfCJ6YfD
変換とかそういう不安定要素は排除しろ
104:login:Penguin
11/08/07 23:26:04.46 5tH5V1VJ
IDEのポートにつないでみれば？
105:login:Penguin
11/08/07 23:35:45.14 NHUTlQqO
そもそもスカジーが付いてるっていつの時代だよ
そんなゴミで何がやりたいんだ
106:login:Penguin
11/08/08 06:15:13.95 J5bJss8h
SCSIは漢のマロン
107:login:Penguin
11/08/08 08:54:33.14 7sot94Dq
コネクタは引退しても、SCSIは永遠に不滅です！ / プロトコル的に
108:login:Penguin
11/08/08 09:46:21.71 ofQq7ek+
お前らSAS(Serial Attached SCSI)を忘れてもらっちゃ困るぜ
109:login:Penguin
11/08/08 10:10:46.67 3bzBx1VS
PC/ATは最初からIDEだったと思うけど
なんでSCSIが付いてんだろ
110:login:Penguin
11/08/08 10:31:31.66 oJ+cvqN8
SCSIってストレージを繋ぐだけの為のものじゃないし
MacでSCSIに繋ぐビデオアクセラレータとかあったし
111:login:Penguin
11/08/08 10:37:00.27 B5lamYMC
知らない奴の質問なんかにいちいち答えなくていいよ
112:login:Penguin
11/08/08 12:42:26.57 RQuM9OPH
それ言ったら2chに書き込んでる奴全員じゃねーかよ
113:login:Penguin
11/08/08 23:16:04.49 B2KLG7t7
>>109
SASIとかじゃね？
114:login:Penguin
11/08/08 23:43:58.20 3+R1NzCu
>>109
ST-506が泣いているわけだが
>>113
あれはガラパゴス規格ですがな
115:login:Penguin
11/08/08 23:45:36.50 kRH0Dm7P
URLﾘﾝｸ(lists.fedoraproject.org)
BTRFS WILL NOT BE THE DEFAULT FILE SYSTEM FOR F16
116:login:Penguin
11/08/09 06:19:28.82 N8ypPLol
バターFS採用宣言キター
117:login:Penguin
11/08/09 10:13:03.24 SElAFBrl
defaultか
思い切ってるな
118:login:Penguin
11/08/09 11:20:32.93 NLHrQ1YT
>>115
>NOT
119:login:Penguin
11/08/09 11:24:29.78 NGWTHhbE
中学生レベルの英語が読めないとはw
120:login:Penguin
11/08/09 12:23:52.02 2c/EE3VL
>>119
>>115は小学生６年生の女の子だよ。
121:login:Penguin
11/08/09 14:38:40.78 NGWTHhbE
>>120
そうか…なら仕方がないな
122:login:Penguin
11/08/09 14:52:27.16 1MTZkVKf
おまわりさん、こいつです
123:login:Penguin
11/08/09 15:02:48.03 hUJrk5uf
このままフェードアウトとかないよな
124:login:Penguin
11/08/09 15:33:09.09 zs0TmHkP
>>120
なんで俺なんだよ
125:login:Penguin
11/08/09 22:26:02.32 BURgDdiS
Linux(ubuntu10.04)にZFS環境作ってるのだけど、ストレージプールから切り出したファイルシステムをext4でフォーマットしないと使えない。
ほんとにそうなの?
126:login:Penguin
11/08/09 22:41:34.85 keykoSck
>>125
ZFSのversionによる
127:login:Penguin
11/08/10 14:38:02.47 LTIBIK6s
トランザクションファイルシステムってZFS以外にありますか？
NTFSはAPIで対応してるみたいですけど、コレはちょっと違いますよね
128:login:Penguin
11/08/10 15:04:15.93 BihZhE+P
URLﾘﾝｸ(journal.mycom.co.jp)
↓
URLﾘﾝｸ(journal.mycom.co.jp)
ぷぷぷｗ
「採用を検討」なのに「採用」ってタイトルの記事書いちゃう人って・・・って当時から叩かれてたけどやっぱりやっちまったか。
129:login:Penguin
11/08/10 15:08:43.86 QnyTvpW6
>>125
Native ZFS for Linuxか？stableの0.5.2だとファイルシステムとしてのZFSは使えない。zpool+zvolだけ。
ファイルシステムをマウントしたいならstableでは無い0.6.0系を使う必要がある。
130:login:Penguin
11/08/10 15:10:42.59 FFE0EJAh
>>127
btrfsはどう?
zfsと同等機能をLinuxに導入するために開発してるので、必要な機能はあると思うけど
131:login:Penguin
11/08/12 02:18:06.96 1O2mM9Fm
このスレで聞くのが適切かどうかわかりませんが、質問があります。
Ubuntu 10.04 に Western Digital EADS 1TB の HDD を２つ取り付け(/dev/sdd、/dev/sde)、
HDD全体を fdisk で lvm で領域確保し、lvm で2TBの領域をボリュームを確保し、
xfs でファイルシステムを作って /hoge として mount しました。
既存のHDD(/dev/sda)からファイルをコピーしているのですが、ものすごい遅いです。
何か原因はありますか？
/dev/sda から別の既存の /dev/sdb や /dev/sdc へのコピーは問題ないので
/dev/sda のHDDの問題ではないと思います。
また、/dev/sdb と /dev/sdc でも lvm でボリュームを作っており、ここへのコピーも
遅くないので、lvm の問題でもないと思います。
/dev/sdd や /dev/sde のHDDに物理的なエラーが出ているのかなと思いましたが、
/var/log/messages等には何も出力されていません。
mkfs.xfs でファイルシステムを作ったとき、すぐにコマンドプロンプトがかえってきましたが
(これはほかのファイルシステムでも同じだと思いますが)、
裏でフォーマットとかをやっているということはないですよね？
132:131
11/08/12 02:27:29.77 1O2mM9Fm
あと、lvmを構成している /dev/sdd や /dev/sde に対して
hdparm -t /dev/sdd でベンチマークをとると、
88MB ぐらいの速度が出ているので、これは適切な計測結果だと思うのですが・・・
133:login:Penguin
11/08/12 02:53:13.63 PpPZzpw0
裏でフォーマット・・・・はないよ
134:login:Penguin
11/08/12 05:53:39.09 JfWCj2bN
EADSって低速病じゃね
ベンチずっとループさせてみ速度落ちたり戻ったりするから
別のHDD買ってくるのオススメするわ
135:login:Penguin
11/08/12 06:13:33.42 VP0j+qPv
私は、WD15EADSで、低速病のディスクに悩んだことがある。
bonnie++で1台ずつディスクのベンチマークを取ってみるといいかも。
低速病のディスクでは、正常なディスクと比べて、どこかの値で、100倍とか
200倍以上とかの、極端な異常値がでた。
136:login:Penguin
11/08/12 16:53:10.62 1O2mM9Fm
レスどうもありがとうございます。低速病かぁ・・・
遅くなりましたが、ハード構成です。
CPU:AthlonX2 5050e
MB:ASUS M3N78-EM
MBのSATAポート1: HGSTの7K500だったか
┗/dev/sda1 → /boot
┗/dev/sda2 → /
MBのSATAポート2: EADS 1TB
┗/dev/sdb → LVM (1)
MBのSATAポート3: EADS 1TB
┗/dev/sdc → LVM (2)
MBのSATAポート4: EADS 1TB
┗/dev/sdd → LVM (3)
MBのSATAポート5: EADS 1TB
┗/dev/sd3 → LVM (4)
(1)と(2)で LVM のボリューム(lv01)、(3)と(4)で LVM のボリューム(lv02)を組んでいます。
lv01はすでにもともとあって、速度も問題なしです。
今回 (3) と (4) は、もともと物理的には接続していましたが、
長らくほったらかしにしていたのを、 fdisk で領域確保からやりなおしました。
>>132 で書いた通り、
/dev/sda ～ /dev/sde すべてに対して hdparm -t したところ、
どれも 88MB ぐらいの速度が出ました。
これは自作PC板とかで EADS のベンチを見ても妥当な数字だと思います。
ただ hdparm は3秒ぐらいしか計測しないから、bonie++ だと
もうちょっとわかりやすく出るのだろうか。
(bonie++ は触ったことがないのだけど、帰宅してみたらダウンロードしてやってみます)
137:login:Penguin
11/08/13 15:35:38.20 3hciOrC+
rar、tar、zipをマウントできるfsってあります？
138:login:Penguin
11/08/13 15:45:20.99 fwZGdaRE
>>137
fuse界隈で探してみ？tgzとかならあったかも。
139:login:Penguin
11/08/13 17:27:49.09 3YwkAMcD
>>137
URLﾘﾝｸ(sourceforge.net)
140:login:Penguin
11/08/15 09:46:41.94 uNWEEpbB
(TOSHIBAの)DVD-VRメディアの内容を、Win7では、ファイナライズして無くても、
ディレクトリ構造やファイル名、内容、を全て読めるのに、Linuxでは、
ファイナライズしなくては読めないんでしょうか？
141:login:Penguin
11/08/16 02:08:22.18 8WPwO2Rm
ここでいいのかちょっと微妙ですけど質問させて下さい
SSD上にcryptsetupで暗号化パティションを作ってbtrfsを使ってるんですが
１．SSDに暗号化パティションは不向きだったりしますか？
２．暗号化パティションで使うのに向いているファイルシステムってありますか？
142:login:Penguin
11/08/16 09:17:13.32 nBJnFNL1
>>141
暗号化でブロックサイズが大きくなるなら不向きかもしれんが、
最近のSSDにはもう誤差みたいなもんじゃないかな。
そういうわけで、特に不向きではなさそう。
143:login:Penguin
11/08/16 10:15:22.09 8WPwO2Rm
>>142
少し安心しました
144:login:Penguin
11/08/16 11:30:17.16 UgzJQxRs
暗号化はブロックが毎回上書きされることになるので、
SSDの寿命的に不向き
145:login:Penguin
11/08/16 13:57:12.22 PHwXvTe8
もう少し考えてから喋れ
146:login:Penguin
11/08/16 13:59:13.13 8WPwO2Rm
>>144
lvmのブロックサイズが4KB
ssdの書き込み単位が512KB
lvmのブロックサイズ＝dm-crypt（cryptsetup）のブロックサイズみたいで
ssdの方が書き込み単位が大きいようです
ブロックサイズを合わせられるなら512KBに近い方が良いんでしょうか
147:login:Penguin
11/08/16 14:27:32.74 vnAfzvcv
>>146
ブロックサイズの問題は、暗号化してなくても同じじゃないの?
暗号化が致命的にSSDに不向きって事は無いはず。
しかも、そのへんはSSDのコントローラがうまいことやってくれるしね。
148:login:Penguin
11/08/16 14:28:43.31 pcZ56tcm
ブロックがっていうか、例えばext3/4側のRAID側の設定探せばわかるけど
ext3系のstripe sizeの設定で512KBにすれば初期化する事なく使用中の
ボリュームをそのままSSDにも最適化できる。ただ、最適化されるのは、
設定されてからファイルが新規が追記された物に限られるけど。
あとブロックサイズを512KBにすると無駄にスペースできちゃって
むしろ低下する場合もある
149:login:Penguin
11/08/16 14:38:41.19 8WPwO2Rm
>>147-148
そこまで気にしなくても大丈夫そうですね
ありがとうございました
150:login:Penguin
11/08/16 18:51:43.71 ejC1a2PW
あんまり凝った事やらなくても、
ssdに最適なファイルシステムってあります？
無ければ無いで、普通にhddと同じ感覚で使うつもりですが。
151:login:Penguin
11/08/16 18:53:25.63 gQJPa5K9
普通に使えばいいよ。
152:login:Penguin
11/08/16 18:55:17.33 zdoyrx7J
btrfs
Fedora16では見送りになったけど、きっとそこそこ安定してるんじゃないかな
153:login:Penguin
11/08/16 19:02:37.51 ozs2wSEo
ZFS
かなり前からSSD最適化とかしてたはず
154:login:Penguin
11/08/16 19:02:48.84 ejC1a2PW
サンキュー！
btrfsってのを試して、そのまま普通に使ってみますね。
155:login:Penguin
11/08/16 20:22:28.00 0FMNreNL
人柱一名ご案内って感じだな。
156:login:Penguin
11/08/16 20:27:10.09 pcZ56tcm
Kernel3.0のbtrfsでインストールしてみて
さあ使ってみようかと思ったとたんに壊れてた
157:login:Penguin
11/08/16 20:51:20.22 8qIdgxFD
さすがにファイルシステムの人柱は怖いな
158:login:Penguin
11/08/16 20:55:51.69 zdoyrx7J
すまぬ…すまぬ…
159:login:Penguin
11/08/16 21:46:28.90 pcZ56tcm
でもシステムで使うのとは別に
機能がいろいろがるから今からいじってみてみるのも悪くないと思うよ
160:login:Penguin
11/08/16 22:37:10.94 0FMNreNL
だねー。本格的に導入され始めたときにノウハウ持ってれば安心だし。
161:login:Penguin
11/08/16 22:52:19.59 UEiUXs4G
ただbtrfsはZFSと違ってロマンが無いからいじる楽しさに欠ける
162:login:Penguin
11/08/16 23:38:07.46 ey97EVul
おい、SSDと言えば必ず出てくる大事なFSを忘れてやいませんか？
163:login:Penguin
11/08/16 23:44:18.97 pcZ56tcm
NILFSか？
homeとかに使うならACLに対応してくれないときついな
164:login:Penguin
11/08/17 00:58:03.36 ulgZImWd
>>150
SSDに特化しているわけでは無いが、フラッシュメディアを対象にしたベンチでext4が良い値を出してた気がする。
メンテナの個人PCがSSD積んでるんで、SSDでのパフォーマンスは気にしてるようなことは言ってた。
165:I can fly
11/08/17 01:05:48.68 2eEztMj9
>>156
mjd? 丁度試そうかと思ってたので人柱乙。
特殊機能使って飛んだ？それともただ使ってるだけで飛んだ？
166:login:Penguin
11/08/17 01:42:58.62 3wxSurzA
HDDの復旧屋が復旧しやすいFSってどれだろ。
ZFSとかはお手上げだったりするんだろうか
167:login:Penguin
11/08/17 02:05:53.39 2eEztMj9
>>166
romfs
構造がシンプルで頭から読むだけ。
168:login:Penguin
11/08/17 11:47:59.89 52p50ODv
>>166
既に復旧事例有り
URLﾘﾝｸ(gigazine.net)
169:login:Penguin
11/08/17 12:45:31.09 crwJN3jV
全部読んじまった
すげーな
170:login:Penguin
11/08/17 13:04:20.65 E9VDvo0E
GIGAZINEって定期的に日本データテクノロジーの宣伝広告記事載せるな
何か関連あるのかね
171:login:Penguin
11/08/17 22:10:59.58 dfRjp0CS
何か関係あるっていうか普通に日本データテクノロジーが金払って広告記事書かせてるだけでしょ
最後にちゃんと「広告」って書いてあるしな 小さく
ここまで盛大に宣伝記事書いてるのはGIGAZINEくらいだけど、色んな所に宣伝記事書かせてるしこの会社は
まぁ膨大な広告宣伝費はどこに転嫁されているんだろうねと思うけど
会社名でググった限りでは利用したいとは思わなかったなｗ
172:login:Penguin
11/08/17 23:14:03.90 vYj10QWO
こういうのにも宣伝広告って明記しとけと思う
URLﾘﾝｸ(ameblo.jp)
173:login:Penguin
11/08/18 01:34:41.45 xJmCxRGX
>>172
まぁこれ読んで宣伝広告と思わない奴はブログタイトルを「広告」とかにしないと気付かないだろうが・・・
しかしまぁこんな胡散臭いブログをわざわざ作るとか、広告手段としての有用性が疑わしい以前に会社としての姿勢が相当疑わしいわな。
174:login:Penguin
11/08/18 02:40:53.55 xrNcbMLL
で、結局ZFS、BtrFS、NILFSは無理なのね？
175:login:Penguin
11/08/18 05:51:37.19 ha7BIYGq
>>172
これはヤバイだろｗ正直あからさま過ぎて笑ったわ。
広告にしてもかえってイメージダウンする勢い。
176:login:Penguin
11/08/18 13:22:33.52 fwHEkofD
>>174
日本語でおｋ
177:login:Penguin
11/08/18 15:19:59.98 xJmCxRGX
URLﾘﾝｸ(ameblo.jp)
URLﾘﾝｸ(ameblo.jp)
URLﾘﾝｸ(ameblo.jp)
URLﾘﾝｸ(ameblo.jp)
URLﾘﾝｸ(ameblo.jp)
URLﾘﾝｸ(ameblo.jp)
URLﾘﾝｸ(ameblo.jp)
URLﾘﾝｸ(hukkyu.blog55.fc2.com)
URLﾘﾝｸ(dishshapekoko.blog59.fc2.com)
URLﾘﾝｸ(qlightaid.blog55.fc2.com)
URLﾘﾝｸ(nihondatatechnology.blog51.fc2.com)
URLﾘﾝｸ(japandatatechnology.blog.fc2.com)
URLﾘﾝｸ(nihondatatechnology1.blog.fc2.com)
URLﾘﾝｸ(blogs.yahoo.co.jp)
ameblo祭りｗと思ったらfc2でも工作活動か、と思ったらyahooもあって探すのに飽きた
どちらかというと宣伝じゃなくて悪評書いてる個人ブログを検索結果上位から消すためにやってるのかな
178:login:Penguin
11/08/18 15:26:10.14 MImNtkZI
よそでやってくんね?
179:login:Penguin
11/08/20 20:11:56.60 MHYkUwZH
【INO】日本ﾃﾞｰﾀﾃｸﾉﾛｼﾞｰについて 6TB【OGID】
ｽﾚﾘﾝｸ(hard板)
180:login:Penguin
11/08/20 22:02:08.83 kBf/2osZ
ところでHans Reiserはいつシャバに戻るんだっけ?
181:login:Penguin
11/08/20 22:09:42.33 eIL1ZARy
みんな、なんでハンスを心待ちにしてるの？
もっと良いファイルシステムなんて沢山あるじゃない。
182:login:Penguin
11/08/20 23:38:00.50 oUL7uibz
ところがパソコン向きなファイルシステムはext4とreiserFSしかない
reiser4はベンチではさんざんだけど体感速度はすさまじい、インチキ臭いほど速い、ありえないほど速い
結局パソコンのファイルシステムで最も重要なのはアプリの起動時間
183:login:Penguin
11/08/20 23:42:07.13 6oTTlVi3
ところでそのreiser4の開発はどうなっているんだね
184:login:Penguin
11/08/21 02:47:46.32 d2+XdVm8
デスクトップだとbtrfsは大仰すぎる気はするわな
ext系は無難すぎるなぁと思ってるクチにはreiserFSの後継はほしいところでしょうｗ
>>179
いつも思うんだが悪徳企業を叩くスレとか単体であってもそこ見られなきゃ（検索で沈めば）業者の勝ちなんだよな。
だから若干関係あるスレで話題にしとくか>>179のように貼っておくべきだな。
185:login:Penguin
11/08/21 05:03:46.82 nFiHmQRI
>>182
それってベンチが駄目ってことなんじゃね
186:login:Penguin
11/08/21 06:43:52.13 iiKBFoqO
reiser4の実力は現在のベンチでは測りきることができないのだ！
187:login:Penguin
11/08/21 07:10:00.31 TN1Y0laB
サーバーを主眼に置いたベンチはパソコン用には的外れなんだよ
例えば
・GNOMEで/usr/libを開くのが最も高速なファイルシステムは?
・Firefoxの起動が最も高速なファイルシステムは?
みたいなベンチがほとんど無い
10万のファイルの作成と削除とか、パソコンではそんな使い方しないから
188:login:Penguin
11/08/21 07:23:19.88 TN1Y0laB
ファイルの作成と削除が速かろうが遅かろうがパソコンではほとんど影響ない、いずれにせよ一瞬
189:login:Penguin
11/08/21 08:41:33.76 LGjPGkCZ
サーバの対義語がパソコンと想ってる人と何を語らえと言うのか。
190:login:Penguin
11/08/21 09:25:59.48 BXIFxcVq
愛
191:login:Penguin
11/08/21 10:47:35.30 Hw7A+g+F
>・GNOMEで/usr/libを開くのが最も高速なファイルシステムは?
ふつーprelink
DT_GNU_HASH
厨にんぐに勤しむGentooさんですか？
192:login:Penguin
11/08/21 11:53:53.83 vy+wlbQ2
lsで同一ディレクトリ内大量ファイルの表示が速いのは？
193:login:Penguin
11/08/21 11:55:24.81 vy+wlbQ2
コンソールの表示速度は、十分に速いものとして下さい
194:login:Penguin
11/08/21 11:55:35.78 LGjPGkCZ
>>192
inodeを参照するだけだからなんでもいい気がした。
195:login:Penguin
11/08/21 15:00:14.08 gus3/f/+
>>192
ls -f
196:login:Penguin
11/08/21 15:18:56.43 I117Deo7
>>192
SSD
197:login:Penguin
11/08/21 15:29:04.61 LGjPGkCZ
>>192
tmpfs
198:login:Penguin
11/08/21 20:12:15.70 gMTy47NK
>>189
なんで対義語になるの?w
サーバーとパソコンは違う、それだけ
ファイルシステムは適材適所
>>191
firefoxの起動の方ね
199:login:Penguin
11/08/21 22:20:25.24 HtA/1XAN
>>188
ext2の削除は目に見えて遅いよ
200:login:Penguin
11/08/21 23:25:01.04 yuu0rxVy
firefox の起動なんて SSD にしときゃなんでも良くね?
201:login:Penguin
11/08/21 23:32:48.72 JiKOHxO9
数秒だよね
202:login:Penguin
11/08/22 00:00:41.14 NHHoXLIQ
起動しっぱなし最強
203:login:Penguin
11/08/22 00:06:37.23 oaGe40wq
逆にHDDだとFSの良し悪しじゃどうにもならないレベル＞Firefox起動
204:login:Penguin
11/08/22 00:13:59.46 B+TVBGDA
二回目以降のアクセスはキャッシュに乗るから
メモリを十分積んで適当なプログラムで先に読んでおけばいい
Firefoxって具体的にアプリケーションがわかっているから先読み可能
205:login:Penguin
11/08/22 01:03:52.49 8n77eUih
John Fremlin's blog: BTRFS hard links in the same directory limit is too small
URLﾘﾝｸ(john.freml.in)
だって。まあ、あんまりないケースだとは思うんだけど、どうなんだろう。
206:login:Penguin
11/08/22 04:23:06.35 55AkqchS
Firefoxとか重いアプリは読み書きする細かいファイルが多すぎるんでしょ。
いくらキャッシュに乗っててもI/Oのオーバーヘッドが大変そう。
スリープ運用かMacみたいにアプリ終了しないでウィンドウだけ閉じとくしかない。
アプリ空間毎にハイバネートしてくれたらいいのに。。
207:login:Penguin
11/08/22 11:03:10.77 qus7X4gh
>いくらキャッシュに乗っててもI/Oのオーバーヘッドが大変そう。
え？
208:login:Penguin
11/08/22 11:27:43.24 xOlZnb2F
HDDのちっちゃいキャッシュでなくて
PCのメモリを使うKernelのページキャッシュの事だぞ
209:login:Penguin
11/08/22 12:57:56.43 EOVaq4+y
cat `find /usr/local/firefox/ -type f` > /dev/null
ってrc.localに書いとけ
210:login:Penguin
11/08/22 13:12:46.03 isdQO5co
↑
それじゃ共有ライブラリが先読みできないから意味無し。
211:login:Penguin
11/08/22 16:24:27.10 8jC5kqe/
>>209
PC起動がすごく遅くなりました><
212:login:Penguin
11/08/22 16:31:39.87 mV3ZWCHS
>>211
本当にやるなよw
213:login:Penguin
11/08/22 16:36:37.57 MrdTbqi7
こういう問題はpreloadを入れておけばおkみたいな話を聞くけど
どうなんだろうね。
214:login:Penguin
11/08/22 17:16:15.83 gUVc6DVU
>>213
preload を入れる
SSDにする
最新のPCにする
これでまるっとすべて解決。ぐだぐだいうやつはバカ
215:login:Penguin
11/08/22 18:02:37.82 9LM3UgFm
バカが何か言ってる
216:login:Penguin
11/08/24 19:17:44.98 XVmpqXmw
WinFSってどうなった？
217:login:Penguin
11/08/24 19:51:44.98 H5zB2w93
>>216
キャンセル。
そして設計意図を継いだオープニング実装も現れず
218:login:Penguin
11/08/24 20:32:44.27 riYNXuo/
>>216
URLﾘﾝｸ(ja.wikipedia.org)
219:login:Penguin
11/08/24 20:37:31.61 AyqTBUkC
得意げにwikipediaを貼る馬鹿ってなんなの？
220:login:Penguin
11/08/24 20:52:02.13 riYNXuo/
別に得意げではないよ。
221:login:Penguin
11/08/24 23:09:05.05 /XQ3wGMb
>>220
おいおいこれから>>219さんがwikipediaに載ってないWinFSの詳細な成り行きを説明してくれるんだから大人しく待ってようぜ。
222:login:Penguin
11/08/25 00:32:22.22 BITZdJ05
何必死になってるの？
223:login:Penguin
11/08/25 00:53:10.42 IvAnECIo
wikiを得意げに貼ってるやつは、周囲にレベル低いやつしか居ないんじゃね？
パソコン博士のゆうすけ君状態だとおもうわｗ
224:login:Penguin
11/08/25 01:37:06.12 QJ15Tbnp
以上、WinFSについて何も知らない一般人のご意見でした
225:login:Penguin
11/08/25 01:45:20.99 BITZdJ05
だから何でそんなに必死なの？
必死で訊いちゃうぞｗ
226:login:Penguin
11/08/25 06:10:15.11 SdQ+289w
WikipediaのことをWikiと略して書く人も十分恥ずかしいと思うけど
227:login:Penguin
11/08/25 09:10:19.24 z9lYwk0b
どっちが必死なんだか・・・ｗ
228:login:Penguin
11/08/25 10:43:14.11 8PlN7IsK
なんで叩かれてんのかよくわかんないんだけど、
URL を貼ることがダメなの?
それとも得意気なのがダメなの?
229:login:Penguin
11/08/25 10:49:29.25 257ddQ7w
>>228
URLだけ貼ってるのを得意気とか感じる素敵な感性の持ち主が紛れ込んだだけ。
230:login:Penguin
11/08/25 12:09:13.40 QJ15Tbnp
単に必死って言いたいだけ
231:login:Penguin
11/08/25 18:33:23.22 SZ3tk6vy
自分が貼ろうとして先越されたんですね、わかります。
232:login:Penguin
11/08/25 18:48:25.56 BITZdJ05
それは100％ありえないｗ
リアルゆとりが火病ってたのか
233:login:Penguin
11/08/25 18:52:41.23 43vFgmn4
煽り耐性0
234:login:Penguin
11/08/26 10:45:56.37 fACGzFTZ
復帰age
235:login:Penguin
11/08/26 22:42:23.39 HvMaht1k
NILFSの発展に１アゲ
236:login:Penguin
11/08/26 23:33:02.48 yf6HLkhY
NILFSってホントひっそりしてるよね。
カーネルのメーリングリストでは活発だったりするのかな？
237:login:Penguin
11/08/27 05:32:38.39 tbbS1s2Z
/にnilfs使えるようになった？ まだ？ なったら教えてね
238:login:Penguin
11/08/27 09:32:57.67 tqmT/8vt
>>236
淡々と、でも着実に活動はしてるね。
カンファレンス発表前になると新機能が入る頻度が増えるような。
イベント駆動開発？
239:login:Penguin
11/08/27 11:36:25.49 ITzQI6P/
中の人１「やっべ、来週の発表どうしよ、ネタがねえ」
中の人２「とりあえず申し込んじゃったからねぇ」
中の人３「じゃ、なんか作っとくか」
240:login:Penguin
11/08/27 13:17:40.23 Qycxzkok
NILFSについて全然知らないんだけど
btrfsの代わりにどっかの鳥でデフォルトFSになる可能性はないの？
1ミリもないの？
241:login:Penguin
11/08/27 13:19:30.08 D5VRrJdp
プロはギリギリまでext3を使う
242:login:Penguin
11/08/27 13:41:15.49 DSyaa6N8
プロほどext3にうんざりしているけどな
243:login:Penguin
11/08/27 14:30:43.88 ITzQI6P/
うんざりするようなこと起こるの？
244:login:Penguin
11/08/27 14:33:44.09 UlECcl1w
飽きたんじゃね
245:login:Penguin
11/08/27 17:24:36.23 dypdfOKq
>>240
ACL とか未対応だったと思う
その辺対応しないとデフォルトにはならないんじゃないかな
そしてNILFS は今のとこそういう用途は狙ってないようにも思える
246:login:Penguin
11/08/27 20:22:09.23 LYdFvRwW
現時点でデスクトップ向けのFSは何だろうね?
ファイルの作成・削除・移動なんかが速いのが向いているかなと思うが。
247:login:Penguin
11/08/27 20:48:02.70 UysgpJMB
あと10年はext3でよい
248:login:Penguin
11/08/27 21:13:49.80 s/bxC8nR
うちのext3ディスクがディレクトリ内のファイル数の多さでパフォーマンス落ちってるんだが、改善しようと思ったらbtree系？
一ディレクトリに10万くらいのファイルがあるんだわ
249:login:Penguin
11/08/27 21:16:42.41 vqdZWUzf
>>248
一度tune2fs -l で調べてみたら
250:login:Penguin
11/08/27 22:03:00.94 s/bxC8nR
>>249
㌧。
現状は
＞Default directory hash: tea
です。これって後から変換可能なんですね。知らんかった。（厨房丸出しでｽﾐﾏｾﾝ）
再フォーマットを考えてたんですが、変換も検討してみます。
251:login:Penguin
11/08/28 04:33:51.39 kK1Dpmt4
>>240
nilfs2 は fstabに書いても動かないから / に使うことができない。
その理由により、nilfs2がデフォルトFSに採用される可能性は１ミリも無い。
nilfs2 は起動後にユーザーが自前でマウントして使う方法しかない。
252:login:Penguin
11/08/28 05:22:05.98 50GtEVIM
URLﾘﾝｸ(fedoraproject.org)
ext4が生まれた時にMatthew Wilcoxがext3のfixがext2にバックポートされてないと言っていたことを考えると現実的な選択なのかもな
253:login:Penguin
11/08/28 08:47:54.90 csO8uN4Y
/をnilfs2にしてた俺が通りますよ
254:login:Penguin
11/08/28 09:24:58.73 kK1Dpmt4
>>253
マジか！！やりかた教えろ！！
教えてくださいお願いします
255:login:Penguin
11/08/28 09:55:57.12 gxmAxVvg
>>251
initram使えば問題ないよ
256:login:Penguin
11/08/28 14:30:30.23 AN0teVAz
やろうと思えばfstabなにそれなZFSだって/にできるご時世だからな。（Linuxでね）
/boot/grubだけext3とかにしておけばいいんじゃない？
257:login:Penguin
11/08/28 20:00:23.43 9gaD+4gM
>>253
NILFS作者降臨？
258:login:Penguin
11/08/28 20:08:15.58 dooK2rXa
作者は無理だろ
/が飛んだら開発出来ないｗ
259:login:Penguin
11/08/29 00:21:18.51 8pdTVzUj
FS開発者たるもの、ドッグフードを食べなきゃ仕事にならんでしょ
260:login:Penguin
11/08/29 00:22:43.69 8pdTVzUj
NILFSが/だと、rm -r /をやっても安心ってことですよね？
261:login:Penguin
11/08/29 00:24:49.41 MxT8fhNo
>>260
自力回復は無理じゃね?
別のマシンに繋いで復活するか，LiveCD とかで復活しないと
262:login:Penguin
11/08/29 00:28:42.17 tKiG0Ci/
>>261
でも、そうすれば確実に復旧できるわけで
ほかのFSじゃそれでundeleteかけても100%復元できる保証がねえ
263:login:Penguin
11/08/29 00:33:11.61 RXzbjQPt
rm -r / なんてミスしないだろｊｋ
もっと恐いのは
cat /dev/zero >/dev/sda1
264:login:Penguin
11/08/29 05:53:40.07 jB+GFx0e
WindowsからLinuxサーバーにファイル転送しようとしたんだけど
一部のファイル名が、ext4のUTF-8 255バイト制限に引っかかっちゃって転送できなかった。
NTFSのUTF-16 255文字と同等以上のファイル名をLinuxで扱う方法って何かある？
やっぱLinux側でもNTFSで運用するしかないですか？
265:login:Penguin
11/08/29 06:55:58.08 ATvWsy30
ext4で扱う方法はない
reiser3/4かntfs-3gだろうな
266:login:Penguin
11/08/29 07:02:26.44 jB+GFx0e
>>265
ありがとう。パフォーマンスやパーミッションについて拘りはないので
ntfs-3gを使ってみようと思う。ただ書き込みの信頼性が少し心配だけど・・・
最近のntfs-3gだったらファイルぶっ壊すようなことはない？
267:login:Penguin
11/08/29 07:55:56.88 RHFtnVsB
>>266
ntfs-3g俺も怖くて使えない。運用したら経過報告よろw
268:login:Penguin
11/08/29 08:11:55.90 IFX/lWW1
>>264
HFS+はたしかUTF-16で255文字いける。
でもMacとWin間でファイル共有するとマッピングの違いか濁点/半濁点が分離することがある。
Linuxでの実装はよく知らない。
269:login:Penguin
11/08/29 08:50:01.39 kFgiEtmZ
しかし 255 文字制限とか、そろそろ無くなってくれないものか。
あっちの人は困らないのかね。
270:login:Penguin
11/08/29 09:16:15.42 eDECTl36
>>268
Ubuntu(ext4)からiPhoneにファイル転送したらブ→フ"みたいになったのはそういうことだったのか
271:login:Penguin
11/08/29 12:02:09.01 I93hXaFX
マッピング関係ないよ。Unicode正規化のせい。
Unicode正規化でそのままぐぐるといい 軽く鬱になれる
272:login:Penguin
11/08/29 13:42:45.85 GCsF2yZ4
ntfs-3gは古いバージョンじゃなければぶっ壊されたこと無いなぁ
なるべく避けてるけど
273:login:Penguin
11/08/29 14:07:12.04 qYHYV8sn
ファイル鯖をZFSにしてやればファイルシステムで正規化制御できるぜ！
って、ZFSもファイル名255バイトなんだよな・・・
最大容量だとか最大ファイルサイズとかは途方もなく大きくするのになんでファイル名はこんなケチくさいんだろうか。
ところで詳しくないんだけど、FS以前にsambaとかのプロトコル的に大丈夫なのか？＞ファイル名文字数
274:login:Penguin
11/08/29 14:20:18.47 MxT8fhNo
eCryptfs でファイル名も暗号化すると更に短く><
前試してみたら255byte のｆｓ の上で144byte だった
144だと結構引っかかって困るorz
275:login:Penguin
11/08/29 14:26:38.33 Dzdwnk4q
ファイルになんでも情報を埋め込む風習バカみたいだからやめて欲しい。
特にWindowsユーザ。
とはいえ255byteは少ないのは同意。
276:login:Penguin
11/08/29 14:27:40.92 x/RAQkq+
>>275
「名」が抜けているw
277:login:Penguin
11/08/29 14:30:08.37 Dzdwnk4q
>>276
指摘ありがとうw
278:login:Penguin
11/08/29 15:46:44.86 WLhx4ugh
むしろ255バイト以下のファイルはファイル名に積極的に情報保存するべき
279:login:Penguin
11/08/29 16:20:55.54 2PpH12ct
むしろ255バイト以上のファイル名はファイル内に積極的にユーザが保存するべき
280:login:Penguin
11/08/29 17:59:07.88 v7vHaHSK
むしろ255バイト以上のファイルはファイル内に積極的にユーザを保存するべき
281:login:Penguin
11/08/29 19:32:43.58 jB+GFx0e
いろいろと忠告ありがとう、特に>>272。
ネットワーク上にMacは無いので、わざわざHFS+を選ぶ意義は薄いし
ReiserFSもメリットを感じない、というより開発情勢が
ゴタゴタしてるのがなんかイヤだし。
ntfs-3gならLinuxに限らず幅広く使われてるおかげで
膿は出きってる、であろうと信じたい。
まぁSamba他、外的要因でまたトラブって
あきらめてまたWindows使う羽目になりそうな気もするけどw
282:login:Penguin
11/08/29 20:53:02.43 ooeXRHma
>>281
ntfsはusbメモリとか外付けhddとかで使っているけど、ファイルが消えたことは
今のところないが、fatがやばかった。
linux側でfatフォーマットしたusbメモリはファイルは消えるわ、win側にさしたら
壊れてるといわれるわで、使い物にならなかった。
そのusbメモリはlinuxでntfsフォーマットされて元気に動いてるし、外付けhddは
isoファイル放り込むと単体で仮想ドライブとしてマウントできる機能がついてるやつ
なんだけど、この機能もlinux側でntfsフォーマットされてきちんと動いてる。
難点は取り外すときにちょっと時間がかかることくらい。
クリティカルな用途は知らないけど、ちょっとしたファイルのやりとりくらいなら
問題はないと思うよ。
自分の中ではfatよりもntfsの方が信頼できる。
283:login:Penguin
11/08/29 20:59:04.08 8pdTVzUj
exfatの話題はここでいいですか
284:login:Penguin
11/08/29 21:42:56.69 CyXaDo+Z
exFATそのものの話ならドザ板だろ
Linuxで使えるようにするプロジェクトはどうなってんの、って話ならここでいいんじゃね
285:login:Penguin
11/08/29 21:57:06.30 RhlzdsrR
>>282
fatよりntfsの方が信頼できるっていうのは仕様からして当然のことなんだけど、なぜか俺の経験則では逆なんだよなぁ。
ntfsは不良ブロックが発生した不良箇所にとどまらず、（ソフトウェア的に）データの壊れるファイルが拡大して被害箇所がディスク全体に拡大する感じだった。
一方fatの方は不良ブロックにあるファイルに被害箇所が限定されて、それ以上被害が拡大することは無かった。
うーん、何でだろ？
286:login:Penguin
11/08/29 22:27:16.20 msnmes2c
>>275
検索機能の貧弱さと
ファイル名とファイルの中身以外は保証されない現状が
原因であるんだよね
NTFSのストリームやLinuxのxattrを一緒にコピーしてくれないツールが多いし
日付もツールやOSの挙動で簡単に変わっちゃうし
ファイルシステムレベルでタグ情報でも保存できれば違うんだろうけどな
287:login:Penguin
11/08/30 00:47:54.63 WhSZomVj
>273
path の長さとかは POSIX とかで決まっているものを
うかつに長くすると困る場面があるんじゃないの?
288:login:Penguin
11/08/30 02:01:14.14 mqkLZqTt
255byteだとUTF-8だと3分の1になってしまう
やがりCJK圏が声を上げないと変わらないんじゃないか
289:login:Penguin
11/08/30 03:32:58.99 F+Lcx9tK
現実的な解法としてNTFS->linuxのFSのパス名長さはどう対処すればいいでしょ？
loopでマウントするしかないのかな
290:login:Penguin
11/08/30 05:43:22.08 62wzevbO
euc -> utf8 の変換時は4T ほどのデータのうち10個くらいだったので適当にrename して逃げた
291:login:Penguin
11/08/30 11:18:51.81 +M8u4dkk
UTF-8 で 255 バイトを越えるようなファイル名なんて、俺はやだけどなぁ。
ざっくり言って、全角(という言い方もどうかと思うけど)で 85 文字以上でしょ?
俺ならディレクトリを掘って、その下にもっと短い名前でファイル名をつけるけど...。
そんなに長いファイル名をつけたいと思うような状況が思い浮かばないなぁ。
そういうやつのデスクトップって、いったいどういう表示になってるんだろ。
292:login:Penguin
11/08/30 12:04:12.67 knkYGXm7
自分では付けないけどプログラムが使ったりしてね。
一時期 Mercurial がひどかった。
293:login:Penguin
11/08/30 12:09:26.19 ZvHyi+oq
ファイル名にmd5sumやsha256値を付けときたいんで、255字以上必須です
294:login:Penguin
11/08/30 14:41:08.95 WhSZomVj
>293
最初から ZFS 使えよ…
295:login:Penguin
11/08/30 16:42:11.08 slHjltA5
ZFSなら255字以上使えるというのですか！？
でもOS乗換えないといけないので却下ですね
296:login:Penguin
11/08/30 17:03:07.49 1/fgslks
zfsならいちいちファイル名にchecksum入れなくてもメタデータに入ってるからおkという意味じゃなかろうか。
まあbtrfsでも同じらしいし、zfsはlinuxでも使えるみたいだけど。
297:login:Penguin
11/08/30 20:32:12.01 GKFOcKRZ
>>291
全角でも半角でもUTFなら3バイトだろってのはまあわかってるだろうけど
ファイル名でファイルの分類とか始めるとまあ255バイトじゃなくて255文字せめて欲しいんだよなあ
システムファイルしかないようなマシンならともかく、ユーザーデータ置くならそのくらいは欲しい
データ置き場にしてると、ディレクトリだけでパス名の半分くらいもってかれるし
298:login:Penguin
11/08/30 20:59:13.40 CwhYpW0b
UTF-8はASCIIと互換性があって
ASCIIの範囲は1byte
日本語の範囲はだいたい3byte
02面の漢字は4byte必要
299:login:Penguin
11/08/30 22:48:07.32 UkwlPz0k
ここは声のでかさでは並ぶものなき豪傑の中国と韓国に要望を出してもらうしかないな。
中国あたりは開発者も結構送り込んでるだろうから、彼らが一斉に要望を出して
サンプルコードをちょっとつければ、欧米の連中が動いてくれたりしないかな。
中国とかでは問題にならないのかな、ファイル名の長さって。
300:login:Penguin
11/08/30 23:16:28.26 +M8u4dkk
>>297
俺は「ファイル名でファイルの分類」とか意味わかんないなぁ。
CP/M使ってるんじゃないんだから、階層ディレクトリでツリー構造にするよ。
仮に分類に255文字以上必要だとしても、それを何階層かにわければ、
ひとつのディレクトリまたはファイルあたりUTF-8で255バイト以下に収めることはたやすいんじゃない?
それすらできないんなら、そもそも、そのようなファイル名の付け方は何ひとつ「分類」してないとしか思えないけど。
何かおれ、論点ずれてるか?
301:login:Penguin
11/08/30 23:24:13.24 WhSZomVj
> データ置き場にしてると、ディレクトリだけでパス名の半分くらいもってかれるし
意味わからん
directory名含めた path長は通常の unixen では 1024くらいあったはず
302:login:Penguin
11/08/30 23:27:18.60 /gLvZKy7
まぁ自分だけで使うならファイル名は短くしてディレクトリで分類もアリだろうけど
ファイル鯖にするならそうじゃない考えの人も使うからな
303:login:Penguin
11/08/30 23:27:23.22 vXBweIlb
Windowsでの話だろ
304:login:Penguin
11/08/30 23:38:22.28 +M8u4dkk
>>293
それも説得力に欠けるなぁ。
sha256つけたって、ファイル名が16進表記で64バイト長くなるだけだろ?
305:login:Penguin
11/08/31 00:04:44.19 8VZXfln9
日本語でファイル名なんか付けたら、cdしずらいし、
vi の引数に渡すにも、いちいち日本語入力しなきゃいけないし、TAB補完もサクサク行かないしで、
実際に使うと、不便極まりないと思うんだが…
ファイル名なんて識別出来れば何でもいいんだから、どうしても日本語にしたいなら mkdir aiueo みたいに
ローマ字で付けたほうが実用的じゃね？ TAB補完もサクサク行くし。
306:login:Penguin
11/08/31 00:15:53.98 UvVevw+d
>>301
~$ uname -a
Linux foo 2.6.38-2-amd64 #1 SMP Sat Apr 23 18:47:49 UTC 2011 x86_64 GNU/Linux
$ getconf -a|grep PATH
PATH_MAX 4096
だそうな
307:login:Penguin
11/08/31 00:56:28.74 CRPr7Quk
>>305
利便性も結局、使い方で変わる
GUIでファイラ使ってるような人ならファイル名を打つことは基本ないわけで
それなら見やすい日本語ファイル名のほうが便利、という考え方もできる。
308:login:Penguin
11/08/31 01:05:30.74 rWjNDSCB
GUIでも閲覧性が悪すぎる
309:login:Penguin
11/08/31 01:11:51.99 VYJU+s8f
>>308
それはファイラの問題
310:login:Penguin
11/08/31 07:13:41.88 dwXRbNBa
なんでこんなに抵抗が大きいんだ？
ファイル名255byteでいいだろ派の言い分は、
俺達は255文字で十分だから、お前らが変えろ、
なんていうトンデモ主張だし、
言い訳でPOSIXを持ち出したりする。
255文字で困っている奴の言い分を全く理解してないじゃないか
linuxカーネル開発界隈はこんな言い分がまかり通るのか？
もういい、俺はFreeBSD に移る。
311:login:Penguin
11/08/31 07:19:43.50 zKUo47Uy
255バイトって2chのどんな板のスレタイより長いよ
むしろおまえらが255バイトに合わせるべきなんじゃないの？
312:login:Penguin
11/08/31 07:21:27.48 WRVO6O35
LinuxのKernelMLに投稿すればいいじゃん
優秀な日本人として向かえてくれるかもしれんぞw
313:login:Penguin
11/08/31 07:31:28.50 dwXRbNBa
>>311
もうそういう言い方は聞き飽きたので。
それに世間一般のファイル名の話であって、2chのスレタイ長さの話はしていません。
あしからず。
314:login:Penguin
11/08/31 08:59:13.39 jGB+k5Kr
samba でファイルサーバにしてると偶にオーバーしてるのを見かけるね
IE のbookmark とかよく見かける
315:login:Penguin
11/08/31 09:31:30.20 YrjzeGC3
> 255文字で困っている奴の言い分を全く理解してないじゃないか
いや、だからその「言い分」を理解しようとしてるのに、
説得力のある説明が未だにないんだが。
316:login:Penguin
11/08/31 09:39:04.47 8q4YcP4D
>>314
たまになぜかMAX_PATHを超えるパスのファイルが作られていたりするから困る
317:login:Penguin
11/08/31 10:38:46.63 gDPqCwQV
たぶんboo()が嫌われるのと同じなんだろ
見にくく目立つから居るだけで鬱陶しい
318:login:Penguin
11/08/31 14:21:41.08 VYJU+s8f
FSレベルでラベルやタグ付け出来たらいいな。
319:login:Penguin
11/08/31 16:03:57.69 xGiaaUCE
xattrでやれば？
320:login:Penguin
11/08/31 17:36:26.56 WRVO6O35
xattrってバイナリも埋め込めたんだっけ?
321:login:Penguin
11/08/31 20:04:36.49 KU00uB84
>>310
まあ、コード書かない人の相手はしないのが基本の世界みたいだから仕方がない。
freebsdもそんなに変わらない、というかもっとひどいと思うよ。
まあ、2chで要望書かれても…てのがみんなの本音だと思うけどね。
とりあえずメーリングリストにでも英語で投げてみてはどうだろう？
意外な反応が返ってくるかもしれないよ。
322:login:Penguin
11/08/31 20:11:37.11 K6mzNIhl
やりたいことからするとlong pathnameよりもsemantic filesystemの方向じゃね？って話かと。
323:login:Penguin
11/08/31 20:56:42.55 zKUo47Uy
EXT4_NAME_LENを適当な数字に書き換えてコンパイルするとあら不思議
324:login:Penguin
11/08/31 21:00:40.31 VYJU+s8f
>>323
vfsで制限かかってない？
325:login:Penguin
11/08/31 21:18:42.11 ZOxx7+Ly
>>321
「化石なFSのためのlong filename拡張です」と言いながらVEXT4拡張のパッチ投げるとウケるかもね。
複数のファイルエントリを使って実現するの。クリスマスとか笑って流してもらえるよう次期は選ぶが。
inode数ですら可変無限大になるんだから、いつかファイル名もそうなるだろう。
326:login:Penguin
11/08/31 22:45:32.98 JEyWF4vH
>>315
説得力は必要ない
運用上足りない状況があればそれで十分だろ
327:login:Penguin
11/08/31 23:21:40.73 YrjzeGC3
>>326
俺は何も使い方を非難してるんじゃなく、そういう使い方をしてるやつが
どれくらい困っているかを理解したいんだが。
>>293 にしろ >>297 にしろ、困ってるという状況が全然見えてこないのよ。
これ以上は具体例でも挙げてもらわんと水掛け論になってしまうぜ。
328:login:Penguin
11/09/01 00:08:45.42 fE3ehtYw
WinFSって実は期待されてたんだぜ
上記の話の問題が解決するから
従来のファイル管理は場所をベースとした考え方なんだけど
タグをベースとした管理の考え方もネットユーザーを中心に浸透してる
ただ、それを直接扱えるシステムが無いので長いファイル名とか歪な物が出現する
>>319
xattrはデフォルトでは無効になってるものが多いし
xattrの保全は保証されてない
unixの世界では重視されてないけど名前も案外重要な情報なんだ
329:login:Penguin
11/09/01 00:27:15.90 fE3ehtYw
/音楽/ロック/90年/バンドX/曲A
/音楽/90年/ロック/バンドX/曲A
上記の二つはfsの考えでは別の物を差すんだけど
ユーザーとしては同じものを指して欲しい
あと絞り込み条件検索も出来て欲しい
それに上記の形だと一覧性が悪い
ってことでタグ付けによるfsも期待されるんだけど
そんなものは無いので
（音楽）[ロック][90年]【バンドX】 曲A
こんなファイル名が現れる
これはOS標準の機能で絞り込み検索が出来るし
一覧性も良くなる
依然として、微妙に違う名前で同じものが登録されることはあるけど
改善はしてる
330:login:Penguin
11/09/01 00:31:22.35 u2Rg3W6o
"tag based filesystem"でググれば色々出てくるだろ
もちろんfuseだけど
331:login:Penguin
11/09/01 02:15:14.32 U52AOByW
パッと見一番長そうな日本語ファイル名で30文字前後だったし自分は255byteでも全然困らない。
が、気分としては>>273と似た感じでなんで現実的に到達しうる制限があるんだろうという感じ。
FSが「ファイル名は短くするべき」という設計思想があった上で作られてるならいいんだけどね。
まぁあんま長くても結局パス長の問題で無意味とかなんだろうけど。
あとUTF-8の問題なんだが255byteって3byte圏の人間としてはなんか気にくわないみたいなｗ
>>311
「2011-09-01 スレタイ.html」みたいなことすると足りない可能性があるというわけか。
>>329
でもってタグによる検索結果をショートカットにしてMacで言うところのスマートフォルダのように使えばいいわけか。
332:login:Penguin
11/09/01 02:30:33.30 aG12//Le
iTunesあたりで取り込んだ曲名が長くて、Unix系OSに転送しようとしたら
255byte制限に引っかかったという話は数回みてるよ。
曲名 feat. xxx, yyy and zzz
みたいな感じでアーティスト名が列挙されてるケース。
333:login:Penguin
11/09/01 10:15:46.42 RVXUBzQf
素直にデータベース使えよと思う
334:login:Penguin
11/09/01 11:56:34.68 CTHP+aRG
WinFS「呼んだ？」
335:login:Penguin
11/09/01 16:52:43.73 UejERtTc
ja_JP.EUC-JPの復権ですよ
336:login:Penguin
11/09/01 19:00:35.63 bQKeLpzE
>>333
ほら出た。
すぐそういう言い方をする
なんで長いファイル名を使いたがっている一般人が扱えないものを持ち出して反論するの？
おかしいと思わない？
WinFS復活させて、こういうおかしい奴等にガツンと言ってやってくださいよ、バルマーさん。
337:login:Penguin
11/09/01 19:20:12.73 bdPYDUmi
なるほど、これだけウザければ適当にいなそうと思うのも仕方ない
338:login:Penguin
11/09/01 20:11:42.00 AgU7/NXq
>>336
AV系のコンテナファイルならタグ埋め込めるんだから、
どうしてもパスベースで管理したかったら
タグを元にリネームして正規化すればいいんじゃないの？
必要なら元ファイル名からタグを生成して。
一般人ならBoxeeやiTunesみたいなプレイヤーつかうから
あんまファイル名は気にしないとおもうけど、逆に。
339:login:Penguin
11/09/02 01:32:25.04 JE+A4awQ
スレチだけど、そんな長いファイル名をどんなファイラで表示させるのかなあ。
340:login:Penguin
11/09/02 02:09:23.66 drBmlNLl
エクスプローラでいつも見辛いなぁとは思ってる（爆ｗ
341:login:Penguin
11/09/02 02:22:50.12 HPqY1Xg9
日本語ファイル名も当初はそんなものはやめろという声もあったなと。
これがないと困るなんて理由がないとダメってことはなくて、
簡便に使えるというのは現代の計算機環境では立派な理由だよな。
実装したくなるかどうかは別として。
342:login:Penguin
11/09/02 02:28:14.88 n3/foYfc
linux板は>>333みたいなのばっかりだから相談しても意味ない。
「あるもので何とかしろ」が基本。
工夫すれば使えるものが多いので一概に悪いとは言わないが、
それで本当に解決になると思ってんの？
と疑うレベルの回答が多い。
343:login:Penguin
11/09/02 05:31:00.75 nlARxBbT
じゃあ自分で作ればいいじゃん
344:login:Penguin
11/09/02 05:36:11.95 SzcNf9UM
ディスクフォーマットが固定されてんのにどう解決しろってんだか
345:login:Penguin
11/09/02 06:19:42.66 drBmlNLl
オープンソースなんだから自分で拡張すればいいじゃん
FATに対するVFATみたいな感じでｗ
それが出来ないならそれなりの態度とか工夫があるんじゃないの？
346:login:Penguin
11/09/02 10:13:36.61 44KUYqr4
ディレクトリはinode番号とファイル名の組み合わせがただずらーっと書かれただけのファイルだから
255バイトでなくちゃならないという理由はないよね？name_lenがu8型でなければならない理由もないし
347:login:Penguin
11/09/02 10:18:46.49 SklxgrFR
おまいらumsdosがそんなに好きか？
あ、等って一人だけか
348:login:Penguin
11/09/02 10:19:19.19 4CA28qqh
>>345
すぐこれだもんなw
349:login:Penguin
11/09/02 10:39:01.40 44KUYqr4
ファイル名長が1バイトで収まらないといけない理由として1レコードを512バイトのセクタ内に収める必要があるということかいな？
350:login:Penguin
11/09/02 10:49:31.04 jXPaIhSO
>>349
それはないでしょ。
4KBとかならともかく、ディスク上のセクタサイズに縛られる理由はない。
だって512Bも4KBもそこまでシークするまでが仕事の90%だから性能変わらん。
351:login:Penguin
11/09/02 10:51:47.81 44KUYqr4
ext2の頃から
extn_dir_entry
extn_dir_entry_2
の二つが定義されてる理由がよく分からない
外人の中にも255バイト以上にしたい派がいるんかいな？
352:login:Penguin
11/09/02 11:09:04.39 y7ii+ejv
視認性に欠けるのは…ごめん、ムリ
その人のセンス疑っちゃうね
353:login:Penguin
11/09/02 11:20:12.71 rOzAd/Ls
time_tがunsigned intでなければならないのと同じように
ファイル名長が255バイト以下と仮定したコードが
シェルとかコマンドとかlibcとかいろんなところに埋め込まれてるから無理ってことなんすね
354:login:Penguin
11/09/02 11:28:01.87 rOzAd/Ls
time_tはunsigned intじゃないです符号付のlongですすいません
355:login:Penguin
11/09/02 11:54:06.94 Qf0qf7gj
長いファイル名を必要としているのは主に windows を使ってるひと?
なら、 samba の vfs で誤魔化せられんのかな。
356:login:Penguin
11/09/02 12:51:07.30 j18MXpAs
いいや、Linuxをデスクトップに普及させてWindowsを蹴落としたいと思ってるひとでしょ、
長いファイル名が必要なのは
Linuxをデスクトップに使うなんて怪しからん、と思ってるなら、
255バイトどころか32バイトのASCIIのみとかでも問題なしでしょ
357:login:Penguin
11/09/02 13:01:19.06 KUjsgIfQ
ファイルサーバには使えませんね
358:login:Penguin
11/09/02 13:08:04.47 YCIAFDa7
ファイルにタグ付けるってのは面白いし楽だよね。
ああこう言ってるWindows自体にそういうソフト（FenrirFS）あるし。
359:login:Penguin
11/09/02 13:27:26.82 2qZJMmOP
>>358
GNOMEもラベル付けられるんだけどねえ。nautilusか。
これをFSレベルでやれるといいなあ
360:login:Penguin
11/09/02 13:38:25.01 gmSB2nEI
もっと長いファイル名使えるようにしろよという
主張自体に正義はあると思う
かつて 8+3文字の FAT をバカにしていた
unix側の人間としても「いまや255文字は」という
主張はあってもいい
ただし，実際にそこをある日突然伸ばしたところで
多くの unix 環境のソフトウェアは対応できないんじゃないかな…
基本的な部分こそ共通のお約束の上になりたっているわけで
361:login:Penguin
11/09/02 17:21:18.90 BUs8sPHq
kernel 3.0 になって似たような問題も出てるねー
まあどっかで対応しないといけない問題だと思う
362:login:Penguin
11/09/02 17:25:51.14 DpBEzWNl
誰かpostgresqlのDBがFSになるような、fuse作って下さい。
363:login:Penguin
11/09/02 17:31:50.98 SklxgrFR
ggrks
364:login:Penguin
11/09/02 18:58:40.27 DpBEzWNl
ん？ 新FSの名前ですか？
ggrks FS？
365:login:Penguin
11/09/02 20:16:39.43 zQMZBEUj
やっぱ8.3ファイル名最高や
366:login:Penguin
11/09/03 16:39:34.45 ScrDtnIK
ニルスって研究用のみなの？
それとも、実際に業務での使用に耐えられるように改良される予定はあるの？
367:出来杉君 ◆B3hX8Wdksg
11/09/03 19:11:15.37 5q34rw0g
>>4
呼ばれた気がした^^;
368:login:Penguin
11/09/03 19:14:32.47 ka2sOK9s
わざわざ検索して来たのか
自己顕示欲の強いナルシストだな
369:login:Penguin
11/09/03 19:50:57.02 2Ec6ZceK
召喚しました
370:login:Penguin
11/09/04 17:07:37.84 4hTSNFFN
ニルスってなんのことだろう...
371:login:Penguin
11/09/04 17:51:28.84 1lcaSK8E
不思議な旅
372:login:Penguin
11/09/05 06:47:43.78 h3wMFgAv
加橋かつみ
373:login:Penguin
11/09/05 07:05:19.96 ydIaBN7k
ファイルサイズが小さくなっていろんな経験ができるんじゃね？
374:login:Penguin
11/09/05 09:38:36.18 PTCwHiTc
最も障害に強いFSは何ですか？
375:login:Penguin
11/09/05 10:07:01.32 v2xDiidN
乙武FS
376:login:Penguin
11/09/05 11:06:35.96 Br/btA5m
romfs
377:login:Penguin
11/09/05 14:23:34.20 nmLI4dSY
>>375
それ非常に興味あります。GPLじゃないといいんだけど。
378:login:Penguin
11/09/05 14:51:45.88 RxAPrvpn
>>362
psqlfsというのがあったようだけど、Webページにつながらない
379:login:Penguin
11/09/08 00:59:53.33 TUqKr1K1
現状ファイル名長256バイト以上扱えるfs で不具合あるんだろうか
無いんだったら他のfs でも対応は難しくないんじゃないかな?
380:login:Penguin
11/09/08 02:39:48.81 StHd9Sdf
そうなんだよ。
さっさとカーネルコンパイル時の値を65536ぐらいに変更すればいいだけのこと。
試しにリリースしてみて、beta版好きな奴らが、あとはテストしてくれるだろ。
381:login:Penguin
11/09/08 14:11:54.72 XrrDnT5f
reiserfsで使えるって言ってんだろハゲ
382:login:Penguin
11/09/08 15:40:37.00 2f94ftDC
ファイル名をそのままデーターベースのタグに使おうとするから長いファイル名になる
本来ならタグとして内包すべき情報をファイル名として丸出しにしている
383:login:Penguin
11/09/08 16:34:13.60 XN7jGUmF
そりゃファイルシステムがファイル名をキーにするKVSなんだから
自然とそういう使い方になるべ
384:login:Penguin
11/09/08 20:16:40.94 8xXCwCfz
>>382
ディレクトリを掘るといいよ
385:login:Penguin
11/09/08 21:04:27.94 StHd9Sdf
また話がループしてるよ...
386:login:Penguin
11/09/08 21:08:16.99 rPhGu5yx
でHansの近況について
387:login:Penguin
11/09/08 21:51:00.10 HIEW8kpT
4.2BSDからOSってまったく進歩してないのな
WinFS・・・
388:login:Penguin
11/09/08 23:51:14.34 XN7jGUmF
実身・仮身モデルつうのがあったが…
いまいち流行らないうちに終わってしまったのう
389:login:Penguin
11/09/09 00:15:33.08 gvCw0BZD
複数ストリーム対応にして
390:login:Penguin
11/09/09 00:44:33.34 x/PnAw0f
シグマ...
391:login:Penguin
11/09/09 00:56:18.97 QyLFnzlz
>>389
現状、ファイル名と中身以外の可搬性が皆無なので、NTFSの有効な機能だったはずの
マルチストリームもまるで使われていないよなぁ…
392:login:Penguin
11/09/10 16:19:59.50 htZtTuMP
NTFSの次のファイルシステムはでねえの？
393:login:Penguin
11/09/10 16:25:25.36 IWnb3epn
GNOME（nautilus？）だとファイルのプロパティでメモが書き込めるんだけど
こういった機能をFSレベルで欲しいなあ。
ちなみにこのメモ。検索する機能がないorz
394:login:Penguin
11/09/10 17:53:33.01 GrnXZ7YW
>>391
昔のMacOSはリソースフォークなんてものを使っていたが
395:login:Penguin
11/09/10 18:05:20.88 1YAoyG1t
>>394
ファイルのヘッダ部分に4バイトだっけ
396:login:Penguin
11/09/10 18:44:17.48 l5ow9zaB
>>394
ああ、画像データとか文字列データとか、
プログラム中で使うデータをリソースとして格納してたっけ。
CODEリソースなんてのもあったな
397:login:Penguin
11/09/10 19:53:51.75 JCYSn5xC
ファイルに埋め込むと検索が遅くなるじゃねえか
398:login:Penguin
11/09/10 20:35:16.81 GrnXZ7YW
暇なときにでもインデックス作っとけばいいべ
399:login:Penguin
11/09/10 22:55:28.57 p1i+3tmK
あいにく俺は暇じゃないんだ
400:login:Penguin
11/09/10 23:04:54.19 IqeAWT63
わりと暇なんだと思う。
linux板なんだったらext4使っておけばいいんじゃないんかな?
Btrfsも不完全版を開発者に投げっぱなしだし、ext5に似た様なのが実装されるよ。
その内ね。
401:login:Penguin
11/09/10 23:51:13.00 AQL+JQxY
リソースフォークの再発明ですか。遅れておりますなぁw
402:login:Penguin
11/09/11 00:39:02.01 jdrvgBk2
ファイル情報ファイル
発明の予感
403:login:Penguin
11/09/11 02:55:32.76 LhGXI1dI
ディレクトリの実体をディレクトリ情報ファイルに格納するようにすればいいんじゃね？
404:login:Penguin
11/09/11 20:06:48.33 riKz84sQ
>>393
それただのxattrじゃないか？
405:login:Penguin
11/09/11 20:16:20.73 Mt7t5IuV
>>404
マルチストリームで
406:login:Penguin
11/09/12 08:17:12.68 l8ioPsRl
ZFSをWindowsにも実装しろや！！！！！！！！！1111111！111！！！１１！１１
407:login:Penguin
11/09/12 16:17:03.96 8ZGgP3aq
FreeNASスレとか見てると
ZFSもそんなにええもんじゃないように見える
408:login:Penguin
11/09/14 22:10:46.08 hMXSXyfe
FS界のファイナルアンサーZFS。
もうこれ以外のFSはいらないし、考えられない。
409:login:Penguin
11/09/14 23:36:06.21 y53kXZ6V
Btrfsは？
410:login:Penguin
11/09/14 23:47:51.42 5gfbQsPQ
いつ完成するの？
411:login:Penguin
11/09/14 23:50:41.71 y53kXZ6V
ReiserFSも？
412:login:Penguin
11/09/15 00:02:49.27 iQ4VegKd
あれは完成してから宣えって感じ
413:login:Penguin
11/09/15 17:14:13.52 ez2nVzUj
デフラグしてて気付いたんだけど、
ext4ってファイルの書き込み位置を、
内周から外周へ少しずつ変えていってるのな。
ディスク全体に分散して書き込んで行ってるのが何となく分かったよ。
ただ、もうちょっとfallocateの精度を上げてほしいなぁ。
414:login:Penguin
11/09/15 17:27:16.22 M8lTKI7R
>>413
あなたの場合直接ソースを読んで、FSを改良する方向で頑張って欲しいと思うんだ。
自力で別ツールを作るんでなく。
これは煽りで言ってるのではなく。もうパッチとか投稿しているんならゴメン。
415:login:Penguin
11/09/15 18:13:50.81 j8QQuuU4
>>413
読んでて内周と外周が逆のような感覚を覚えるんだが
416:login:Penguin
11/09/15 19:51:39.56 nno+g+lu
アクセスの頻度によって配置してるならすごいな
ReiserFSはもう枯れてる、完成の域
417:login:Penguin
11/09/15 21:25:14.13 ez2nVzUj
>>415
> 内周と外周が逆
そうだった、逆だった。普通に間違えてたよ。
外周から内周へ、だね。
>>414
うーん、流石にそれは無理かな。
そこまで知識と技術があるわけじゃないから。
418:login:Penguin
11/09/16 03:58:36.51 BuOUjDY8
>>408
ライセンス問題が無くてLinuxにデフォで組み込めれば確かにそうだと思うけど。
419:login:Penguin
11/09/17 10:21:22.17 gh696PuM
>407
たとえばどんなところ?
420:login:Penguin
11/09/20 17:19:27.84 z0zt1+wx
実績からいって、ZFS以外あり得ないと思うけど、
ライセンス以外のネックは無いよね
421:login:Penguin
11/09/20 17:50:06.43 Wwly70XG
ZFSの実績？
422:login:Penguin
11/09/21 00:41:35.15 /FZ3c4r8
ソラリスではそれなりにあると思うよ
FreeBSDだとやっと安定してきたって段階らしいけど
なんだかんだでext5が立ち上がるような気がしてならない今日この頃
resize2fsのファイルシステムサイズ上限16TBって修正されたっけ?
423:login:Penguin
11/09/21 00:43:47.03 8iMA/1Y2
ソラリスはufsとveritasしかまともに動かんだろ
424:login:Penguin
11/09/21 00:56:52.58 D4VUvtf5
NetBSDでlfsが永遠に動かないのと同じか
425:login:Penguin
11/09/21 01:52:36.53 sfWqGycT
>>423
Oracle Solaris+zfsってもうあちこちで実績なんだが。。。
案件は減ってるけど、金額ボリュームの大きい（めんどくさい）案件で
導入してるから通常のホームサーバくらいの負荷ならどーってことない。
426:login:Penguin
11/09/21 10:05:26.72 8iMA/1Y2
「導入」実績？
427:login:Penguin
11/09/21 10:58:35.82 kwbX5VAJ
ホームサーバーにZFSってのは、メリット考慮しても、
必要リソースとの兼ね合い考えると最適解か疑問だなあ
428:login:Penguin
11/09/21 12:09:10.69 a1Hj+Tf0
>>427 利用者一人のNASにZFSは無用の長物でしかない
非同期のバックアップで十分
最重要というならクラウドストレージに入れとけって感じでしょう
429:login:Penguin
11/09/21 12:55:09.61 6t7sWIId
ARMで動くシュリンク版Solarisというのもありまして…
430:login:Penguin
11/09/21 14:08:17.55 kwbX5VAJ
>>429
そういう環境じゃZFSなんて使い物にならないから、
ZFSをシュリンクしてFATクラスまで機能削減したzFSが必要と言いたい？
431:login:Penguin
11/09/21 16:03:23.32 Of/LX3Jt
個人用途だからこそRAID1という贅沢はできない、RAID5は危ないからRAIDZ使いたい、という需要はあるんじゃね？＞ZFS
数？十数TBのストレージだと全部非同期バックアップというわけにもいかんし
コストまで考えてもRAIDボード買ったりWinでオンボRAIDやるより安上がりだし
432:login:Penguin
11/09/21 16:16:07.04 a1Hj+Tf0
>>431 何十TBあろうと、バックアップが一番安上がりじゃないかな
電気代とか・・・
2TBx18の36TB を同じく2TBｘ18の36TBで週1でバックアップ取ってるよ
バックアップはミラー(更新上書き)で平均数時間で終わるので月に20～30時間程度稼動する感じ
バックアップが終わると勝手にシャットダウンする
何がいいってどんなOSでもHDD単体でリストア・アクセスできるので、RAID系のトラブルとは無縁な点かな
433:login:Penguin
11/09/21 19:19:11.76 7RVPFeqF
zfs、メモリ消費とraid zしたときのcpu負荷がきついな。
434:login:Penguin
11/09/21 19:30:45.07 e/hLzBp7
でも、メモリも安くて手に入るしなー。
435:login:Penguin
11/09/21 20:20:59.31 m3wbiRtN
>>430
あれは 128MB のメモリで動くように ZFS もチューンされてるのよ
日の目を見ないのは実に勿体無い
436:login:Penguin
11/09/21 21:23:27.92 F0TO9L3v
ID:8iMA/1Y2はたぶん、ものすごいバカ。おまけに包茎。関わると恥垢臭がうつるので
放置推奨。
437:login:Penguin
11/09/22 12:08:37.19 BL2XoA4T
>>435
まじか、それは知らなかった。しかしZFSの仕組み的に、
10TB単位のストレージをそのメモリ量でハンドルできるとは到底
信じられないのだが、どういう魔法的な技術が使われているんだ？
438:login:Penguin
11/09/22 13:19:20.82 ZpYKl2c/
>>437 いや、理想はそうでも実際はそんなメモリでは動かないからね
10TBだと最低OS抜いてZFSだけに5GBは無いと死ぬだろ
まぁ今は16GBまで積めるから30TBぐらいはいけんじゃね
439:login:Penguin
11/09/22 13:58:17.20 4PDiV5It
zfsがメモリがたくさんいるのはわかったけど、
それじゃホームサーバに10TB,30TB必要な時にzfs以外で最適解はなに？
2TBディスク5本で10TBだから簡単な時代だからねぇ。
fsck走って1日2日っていうのは勘弁だし。
440:login:Penguin
11/09/22 14:08:37.02 m9bnXgpH
xfs
441:login:Penguin
11/09/22 14:35:43.34 QAmCAelX
>>440
だな
442:login:Penguin
11/09/22 17:20:07.52 ZpYKl2c/
>>439 DrivePoolかな二重化しかないけど、メモリは要らないよ
443:login:Penguin
11/09/22 18:33:11.00 2PnZcMLv
＞fsck走って1日2日っていうのは勘弁だし。
なんかext3が最新だった辺りの時代から来てるのがいるな
444:login:Penguin
11/09/22 19:02:48.16 ZpYKl2c/
>>443 おまえ10TBという物理サイズ舐めてないか？
HDDの転送速度を超えることはないんだぜ？
445:login:Penguin
11/09/22 19:06:09.70 DMao/mOM
ふつーtune2fs -c 0だろ
446:login:Penguin
11/09/22 21:52:28.06 QAmCAelX
>>444
24TB+xfsで10分かからん
447:login:Penguin
11/09/22 22:19:55.31 so8FuAcc
fsck.xfsに10分もかかったらビビるわ
448:login:Penguin
11/09/22 22:52:50.06 xtcIORqq
fsck.xfsは時空を超越してるからな
449:login:Penguin
11/09/22 23:02:15.32 GH4Uv3vp
おっとmain関数よりコメントの方が多いfsck.xfsさんの悪口はそこまでだ
450:login:Penguin
11/09/23 00:27:17.18 xynqWG6o
まあ悩んでいる間に底辺のメモリ量も増えて ZFS の時代が来ると
451:login:Penguin
11/09/23 00:30:43.56 Vgb1Rjqv
そこで颯爽とZAFSが登場
452:login:Penguin
11/09/23 10:41:40.95 jkv92p1m
zfsかいいなぁ
おらも高速なマシンがほしいだ
453:login:Penguin
11/09/23 11:10:42.60 XuoYeMN7
btrfsは何をしておるんじゃ
454:login:Penguin
11/09/23 11:57:07.24 TCNR5ivD
今日も人のマシンのファイルを破壊しながら実験中。
455:login:Penguin
11/09/23 11:59:47.73 TCNR5ivD
メタデータのcrcやmd5はファイル破損を検出できるだけで、
修復できないんだよね？
456:login:Penguin
11/09/23 23:09:52.36 jkv92p1m
で結局zfsはひゃいの？
457:login:Penguin
11/09/24 00:05:14.80 b8VyZz6F
速さの方にチューニングしてないと解釈するのが妥当かと
458:login:Penguin
11/09/24 00:05:27.96 CAT4jfZb
自分で試せよ
459:login:Penguin
11/09/24 02:15:39.86 5FxCZPf9
UFSに比べるとZFSは遅い
でも管理の楽さを考えたら許せる
460:login:Penguin
11/09/24 02:22:11.27 YadKppkO
mdadm+ReiserFS+LVM2の方がZFSより良い
461:login:Penguin
11/09/24 04:54:06.74 afYV5Af2
LVM2のスナップショット機能はあんましイケてない印象がある。
462:login:Penguin
11/09/24 20:04:28.90 dgSFexL+
スナップショットはファイルシステム側でもサポートしてないと安心出来ないな。
その点、NILFSなら絶対の安心を提供してくれるけどね！
463:login:Penguin
11/09/24 22:26:17.94 jh+Xip6z
gitサイコー
464:login:Penguin
11/09/24 23:19:50.42 JYVRKTtb
もう端数みたいな価格で8GB積めるんだからメモリ食うは関係なくね？＞ZFS
ローカルで使うならメモリ食いは困るけど大体ZFS使うのなんてNAS/SAN専用機でしょう。
465:login:Penguin
11/09/24 23:29:27.89 RQzuGj/J
>>464
メモリは問題ないがCPU喰いが困る
466:login:Penguin
11/09/25 01:15:50.04 80e20/8S
ノートで使っとるが
467:login:Penguin
11/09/25 05:13:25.47 IwW/FzQG
URLﾘﾝｸ(www.allbsd.org)
FreeBSD での事例の様だけど
業務ではもう少し待ちかねー
468:login:Penguin
11/09/26 19:07:21.49 CbKQ315J
>>467
FreeBSDへのportingはしらんが、oiやその他のSolarisを無料、簡単に使えるので
不安定なFreeBSDにする必要はないんじゃないかなぁ。
俺も5年前くらいはSolaris(Nevada)のzfsでもよくデータを飛ばしたけど今は安定と
思うけど。
469:login:Penguin
11/09/26 19:27:09.90 u/XPB+E1
少なくともバターFSより全然まし。
470:login:Penguin
11/09/26 19:32:23.21 e5m2HaP3
ベットリfsじゃね
471:login:Penguin
11/09/27 13:33:35.52 zwGArpBP
>>464
x64ならそうだが、最近沸いてるarmでサーバーとか言ってる連中には無理だろ
量と帯域の両方で無理だ、それに帯域増やすと消費電力の利点が消える
472:login:Penguin
11/09/27 14:23:21.04 0qLeAjii
なら、exFATしかないか．．．
473:login:Penguin
11/09/28 00:24:04.77 W78OUf+j
NILFS
微妙に使いどころに悩む
474:login:Penguin
11/09/28 01:01:54.89 zX8lTRZB
>>471
そういう奴はRAIDｰZ使わずにファイルシステムとしてZFS使えばいいんじゃね？
どうしてもRAID必要なら別途ハードウェアで
475:login:Penguin
11/09/28 15:50:52.94 Jmh5TnDt
ext4、なんかもっさりする
気のせいか？
476:login:Penguin
11/09/28 16:19:25.16 81rQN3R+
気のせいじゃね、うちではキビキビ動いてる気がする
477:login:Penguin
11/09/28 18:04:36.41 xrEKABkR
ext4は開発途上だからカーネルが新しい方が良いぞ
新しすぎるとバグ入りになりかねんけど
3.0だけど、今のところext3より挙動は良い
478:login:Penguin
11/09/28 18:07:49.19 fWC/EOuJ
>>477 何を持って良いんだ？
479:login:Penguin
11/09/28 18:11:18.19 2ZCg0OML
同じHDDで比較した他のFSを言ってないからコメント出来ないよな。
ext4はもう良い感じで枯れて来てる気がしてたが……。
480:login:Penguin
11/09/28 23:08:20.37 AjWI8pSv
>>479
五年位xfs使ってて試しにext4にしてみたけど、随分こなれてるね
相変わらずlost+found最初から作るのは頂けないけど
ext2の頃からは隔世の感があるなあ
481:login:Penguin
11/09/29 00:06:37.86 3LlZxr4a
zfs on linuxはいつになったら0.6.0stableが出るんだ
482:login:Penguin
11/09/29 00:17:17.12 3qB2B6jL
なんぞこれ
URLﾘﾝｸ(www.allbsd.org)
> こ の へ ん の記事、かなりでたらめなので信じないほうが良いと思います。
URLﾘﾝｸ(gihyo.jp)
> ここで取り上げた内容を補完する素晴らしいドキュメント
483:login:Penguin
11/09/29 14:14:43.28 ZjuJY5oi
>>480
lost+foundはマウント済みの目印に使ってるから
いまさら無くなられると困る
484:login:Penguin
11/09/29 14:24:18.49 XCVk6YPQ
そんな使い方するなよｗ
485:login:Penguin
11/09/30 09:12:30.04 rcdHUGPg
>>484
するだろ。noautoの時は特にそれでマウント忘れに気づくことが多い。
vfatは困るんだよね。
486:login:Penguin
11/09/30 09:52:29.52 uyfCFfv/
ねーよｗｗ
487:login:Penguin
11/09/30 09:55:01.16 ngaR99T7
>>483
/proc/mounts とかじゃ駄目なんか?
488:login:Penguin
11/09/30 10:33:43.33 WYy/QVqU
おれは lost+found は見たくないなぁ。
マウント忘れとか言ってるけど、そもそも >>485 はいちいち手動でマウントすんのかよ。
そもそもマウントしてるかどうかなんて、
ディレクトリが空っぽならマウントしてないわけだし、
空っぽじゃなければマウントしてるということだろ。
それともなにか?、空じゃないディレクトリにマウントしてんのか?
いったい、どんな使い方すりゃそういう発想ができんの?
489:login:Penguin
11/09/30 11:50:02.61 ACR7fMHR
まあいいさ、今度>>485のディレクトリに片っ端からlost+found掘っておいてやるから。
490:login:Penguin
11/09/30 12:15:50.39 rtApsSqF
>>488
> ディレクトリが空っぽならマウントしてないわけだし、
そこで判定はしたくないなぁ。
491:login:Penguin
11/09/30 20:59:24.89 uArDJlFs
>>488
パーティションの再構成中は手でmountして書き戻してる。自動でマウントするのは全作業終了後。
492:login:Penguin
11/09/30 22:21:37.32 iokNb/Mi
>>482
ツンデレなんだよ、言わせんな恥ずかしい。
493:login:Penguin
11/09/30 22:28:02.84 J2pm6fHD
>>485
おまいはdfとかmountコマンド打つ気すらないのかw
494:login:Penguin
11/10/01 01:47:47.13 McvhjrXL
自分は、bind mount してる場合など困るから、
487 と同じように /proc/mounts みてるな～
495:login:Penguin
11/10/01 21:10:14.31 zMBMsVkH
シェルスクリプトで考えると確かにlost+found有無を見るだけってのは非常に簡単で合理的だと思った
496:login:Penguin
11/10/01 21:17:08.87 rOV5RHi3
判別する必要ないぞ実は
497:login:Penguin
11/10/01 21:30:13.90 OkXJrPqL
>>495
/etc/mtabとか/proc/mountsとかmountの出力見るほうがよっぽど合理的じゃないか
498:login:Penguin
11/10/02 00:34:02.92 c0DcHtK6
>>497
mountの状況がprocessごとに違う可能性がある以上、
/etc/mtabやmountの出力見るなんて、lost+foundと五十歩百歩の合理性しかない
499:login:Penguin
11/10/02 00:45:37.65 mEShoWvB
>>498
そういう状況が起こりうる場合を思いつかんので
もう少し詳しく説明してくれ
500:login:Penguin
11/10/02 01:00:37.89 Mw9MOLk6
NTFSパーティションとかの場合はどうすんだろ？
意地でも/proc/mounts見ないのかな。
「俺はそんなFS使わんから知らん」かな。
個人的環境の使い方を一般論として語るからこうなったんじゃ？
501:login:Penguin
11/10/02 02:23:26.58 KF5vOJuy
NTFSはどうかわからんがvfatの時は困っているようだな。
>>485 によると。
「判定に困るケースが出るなら、その判別法は使うべきではない」
とまあ俺は先達に言われたことがあったような記憶があるが、
そういうことなんじゃないのかなあと思ったり。