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

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

175:login:Penguin
03/12/17 00:42 h7X+VEEd
Windowsのntfs.sysを使って、読み書き完全サポート

URLﾘﾝｸ(www.jankratochvil.net)

使っている人います？

176:login:Penguin
03/12/17 01:15 s94VXDx9
>>175
相変わらず犬糞陣営ってやることが汚いよな。
それが必要であるならば正式にライセンスを受けてFAT/NTFSをサポートするのが筋だろう。

177:login:Penguin
03/12/17 02:51 REi6MsFt
>>175
がいしゅつ

178:login:Penguin
03/12/17 15:30 Sq7jarJH
>>176
それはディストリビュータがやるべきことであって、一開発者がやることではない
そもそも犬糞陣営という言葉が意味不明

>>177
このスレでは使用報告は見られないんだが。他のスレにあるなら教えて欲しい。

179:login:Penguin
03/12/17 15:31 jszsTTTz
いないって事だろう。

180:login:Penguin
03/12/17 19:54 REi6MsFt
>>178
>>105-108

181:login:Penguin
03/12/20 14:07 cE4sUZVG
Redhatが買収するSistinaのSistina GFSってどうよ。
また、ファイルシステムが増えるのか？
ファイルシステムの切り札となるのか？

Sistina GFS
URLﾘﾝｸ(www.sistina.com)

米Red Hatがストレージ仮想化ソフトの米Sistinaを買収，全技術をオープンソース化
URLﾘﾝｸ(itpro.nikkeibp.co.jp)

182:login:Penguin
03/12/21 03:57 yU9Oqo8P
買収してオープンソース化か。大胆だな。

183:login:Penguin
03/12/22 12:41 MtdiJSkO
MS買収してオープンソース化すれば、世界中の情報処理に関する問題の
半分は解決すると思うな。

184:login:Penguin
03/12/22 12:51 3Eol6WUQ
>>183
やってくれ。
俺は金が足りん。

185:login:Penguin
03/12/22 15:40 OIox15FM
MSを買って捨てるという手もあるな。
アメリカの自動車会社は昔、鉄道会社を買収して、片っ端から廃線にしたらしいからな。

186:login:Penguin
03/12/22 20:33 1VvqkkGR
The OpenGFS Project
URLﾘﾝｸ(opengfs.sourceforge.net)

187:login:Penguin
03/12/22 21:28 jTZcEXDh
FAT ってこういう感じですか？ｗ
micros~1
micros~2
micros~3
micros~4
　：
　：

188:login:Penguin
03/12/22 21:59 LqXFdWm6
ＦＡＴのライセンス使用料はユーザーから徴収するようになるらしいね。
ディス鳥毎に交渉するので若干の差異はあるけど
大体一人当たりで約\500程度になるらしい。

189:login:Penguin
03/12/22 22:08 jTZcEXDh
>>188
>ＦＡＴのライセンス使用料はユーザーから徴収するようになるらしいね。
>ディス鳥毎に交渉するので若干の差異はあるけど
>大体一人当たりで約\500程度になるらしい。
ソースは？

190:login:Penguin
03/12/22 22:23 cNFguPSo
カーネルが2.6になって、/ をXFSにする人も増えてくるだろう。

191:login:Penguin
03/12/22 22:28 SvcoXU3X
grubにXFSサポートマージされたっけ？

192:login:Penguin
03/12/22 22:30 e85TOeGh
>>191
/をXFSにしてgrubからブートしていますが何か？
MBRにインストールすれば問題ないですよ。

193:login:Penguin
03/12/22 22:38 zxV8yJbp
>>191
とうの昔に

194:login:Penguin
03/12/22 22:41 cNFguPSo
MBRにgrub入れるか、/bootを分けるか。
いずれにしても、インストール時にXFS選択できるようになるのはありがたい。

195:login:Penguin
03/12/22 22:42 SvcoXU3X
とっくに対応してたのね…。

196:login:Penguin
03/12/22 23:32 cNFguPSo
FSだけの問題じゃないかもしれないけど、
ext3で定期的なfsckチェックに失敗して、死んだことがある。
何回かはログをドロップしてfsckし直すことで復帰したけど、一回はそれでも復帰できなかった・・・。

197:login:Penguin
03/12/23 01:12 iEBBukoV
kernel2.6でEXT3も改良されたりしてないか？？？
情報求む。

それにしてもext3かxfsかreiserfsか選択に迷うなー。

198:login:Penguin
03/12/23 01:29 XyxciG5O
>>197
vfatがお勧め。

199:login:Penguin
03/12/23 01:35 PWqhqtob
>>197
umsdosとtmpfs

200:login:Penguin
03/12/23 01:39 DyFvbHWO
>>197
なんといっても cramfs が一番だよ。

201:login:Penguin
03/12/23 02:18 tP/1EZnv
>>197
スケジューラの改良で100倍(たぶん最高で)速くなるという噂をきいたぞ。
どっかのベンチマークに載ってねーかな？

202:login:Penguin
03/12/23 04:23 sAt8hZvd
噂ってこれ?
URLﾘﾝｸ(www.zdnet.co.jp)

10倍となってるけど。

203:login:Penguin
03/12/23 04:25 aQED4S0o
>>185
へえそうなの？

204:login:Penguin
03/12/23 04:30 DyFvbHWO
パフォーマンスにおいて、B-TreeがB+やB*に勝てるわけない。
頼みの安全性も、ログが壊れやすいという欠点がある。

205:login:Penguin
03/12/23 08:30 EEHhN2c8
>>202
ってことは、
>>7
あたりの評価も変わるってことかな。

206:
03/12/23 10:15 xEx5pIB7
>>202
> ディスクの予測型IOスケジューラ採用で100倍以上のスループットを記録

そのページの下の方に書いてあるよ。アンドリューも言ってるが、
投機的ものなので安定して100倍になるわけじゃない。

207:login:Penguin
03/12/23 11:29 MNSuYlGE
>>204
お前、ソフトウェアの実装の経験やアルゴリズムの知識ないだろう?

208:login:Penguin
03/12/23 21:12 CIdlb+tE
降るジャーナル使えるのはext3だけ？

209:login:Penguin
03/12/25 12:41 XEqSb0Vr
>>167
これホント？

(((( ；゜Д゜)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ ...

210:login:Penguin
03/12/25 13:00 mnUhPfX7
コメントの方が大きいぜw

211:login:Penguin
03/12/25 13:11 bcriUYHp
>>167
int main(void)でいいだろ(w

212:login:Penguin
03/12/25 15:32 roL73w1j
>>211
main=-61; でいいじゃん

213:login:Penguin
03/12/26 13:50 0i5/0dKq
Linuxってx86以外にはportされてないんだっけ?

214:ヽ(´ー`)ノ
03/12/26 14:54 HfOJX06c
>>213
Debian が入った LX がそこに転がってる。alpha とかでも動いてたような…。
だから、>>212 じゃダメだな。

215:login:Penguin
03/12/27 02:37 LSe61FSQ
>>167
まじだ、、、すげー

216:login:Penguin
03/12/27 03:42 sOQ5kj7M
>>167
1T以上のファイルシステム組んだとき、安定して動作するのがXFSのみだった、
という話は聞いたことがある。

217:login:Penguin
03/12/27 12:59 lqlbs7fl
befsってもう無かったことにしていいですか？

218:login:Penguin
03/12/27 13:03 4b6cP80H
いいよ

219:login:Penguin
04/01/05 15:43 Ruty/tbr
Windows上から読み書きできることを条件としたときの最適なファイルシステムは何でしょう？

220:login:Penguin
04/01/05 15:58 yZInMRXV
vfat

221:login:Penguin
04/01/05 22:51 WsBzXHhw
ext2 or ext3 ↓
URLﾘﾝｸ(www.holonlinux.com)

222:login:Penguin
04/01/06 06:02 v92W94vt
>>221
これいいですね。
ちなみにReiserFSやXFSはWindowsからマウントできるのでしょうか？

223:login:Penguin
04/01/06 13:02 2b8ooEcT
>>221
＞LinuxDrive for Windowsで対応しているフォーマットは何がありますか？

＞ Ext2とExt3とReiserFSになります。
＞Ext2とExt3はフォーマットおよびマウントを行うことができますが、ReiserFSはフォーマットのみの対応(マウントすることはできません)となります。
＞XFS,JFSは現在フォーマット、マウントともに未対応です。

なんて微妙なReiserfs

224:login:Penguin
04/01/06 16:57 NsLYYq6V
URLﾘﾝｸ(ext2fsd.sourceforge.net)
これどーよ？
ext2 file system driver for winnt/win2k/winxp.
ということだが。

225:login:Penguin
04/01/06 17:59 4xKdc4yV
ext2explorerだかext2plorerってのがあったと思う。

226:login:Penguin
04/01/06 19:00 T+0S/wXL
>>224
これって書き込みも完全にサポートしているの？

227:224
04/01/06 19:34 NsLYYq6V
>>226
V0.09から書き込みもサポートされたみたいだけど。

228:login:Penguin
04/01/06 21:20 2b8ooEcT
>>224
書き込みはやめた方がよさげ
書き込んでLinux起動したらfsck走った

>>225
explore2fs？

229:login:Penguin
04/01/06 22:49 gsToOCUF
力技：
VMWareでLinuxを起動
↓
ハードディスク上のパーティションをマウント
↓
Sambaで共有

230:login:Penguin
04/01/07 02:17 NlTIHiej
>>208 今更のレスですまんが、漏れは、
mount -t ext3 -o data=journal ...
した時に、はデータ本体もジャーナルノードに書きこまれた後に
ファイルシステムに反映されると期待してた。
URLﾘﾝｸ(www.jp.redhat.com)
URLﾘﾝｸ(www-6.ibm.com)
URLﾘﾝｸ(www.zdnet.co.jp)
とかはそう読めるんだけど
URLﾘﾝｸ(www.atmarkit.co.jp)
を見るとどうもデータ本体は別にジャーナルノードに書かれるわけでは
ないようだ。こういうのもフルジャーナルっつーの？

231:login:Penguin
04/01/08 17:51 kceow6QB
質問です。

cramfsでリードオンリーのプチシステムを作ろうと思ったんですけど
普通にブートできない事に、はたと気がつきました。

cramfsのイメージをシステムに書きこんだら、
ブートローダの情報を更新してやる必要があるけど、
cramfs自体がリードオンリーのファイルシステムだから書きこめない。
/bootだけext2にするのもなんかカッコ悪いし、
何かいい方法ありませんか。

232:login:Penguin
04/01/09 22:41 sjKhKFPp
>>231
grubみたいなファイルシステムを認識できるブートローダで
なんとかならない？ググると2002年頃にはcramfs用のパッチが
出てたし。

233:login:Penguin
04/01/09 22:47 JRioanEK
>>221
それなら祖父地図で投げ売りしていたんで買って来た
売価は通販での同時購入版と同じ
ネット通販と違って単独で買えたけど何でだろ
秋葉で買ったが地元の地図も同様だった

FAT32 だと 2GB の壁があるんでこれを使えばそれを越えられるかを試してみるつもり

234:login:Penguin
04/01/10 03:51 Jz5IYJtO
>>233
君がいつもいい子にしてるからだよ。> 何でだろ

235:login:Penguin
04/01/10 10:51 p852A7GC
>>233
あらかじめいっておくが、2GBの壁はFAT32にはまったく関係ない。

236:233
04/01/10 13:36 J1p8bDT/
訂正
2GB の壁ではなくてファイルサイズの 32bit u_int ( 4GB ) の壁
と言う事で宜しいかな >>235

237:login:Penguin
04/01/10 13:59 pXa2Qfmu
Win9x系はOS自体が4G超に対応してへんよ

238:login:Penguin
04/01/10 14:02 q1NOeHL9
80GBのHDDとかをFAT32でフォーマットできるよ。

>>237
それFSとは別の話だろ。

239:login:Penguin
04/01/10 14:16 kTATT3AR
>>238
BIOSの制限　つまりその当時のPC/ATの規格の制限であり
且つFAT16での話だな

240:login:Penguin
04/01/10 14:40 pXa2Qfmu
>>238
悪い、言葉足らずだった
4G超のファイル、に訂正する

241:login:Penguin
04/01/10 17:01 SLKIugxV
>>240
なおさら、ファイルシステムで話す内容じゃないな。まったく関係ない

242:login:Penguin
04/01/13 14:26 hCANnvIj
>>232

れす、ありがとうございます。

それ、実はそれっぽいのがありそうだと言うことは知っていたのですが
肝心のパッチ自体が何処にあるのか分からなかったのです。
どっかのメーリングリストにあったリンクは既に死んでたりで。

とりあえずは/bootはext2ですすめながら、パッチも並行して探して見ます。
どうもでした。

243:login:Penguin
04/01/14 18:06 PPoiLiAT
>>242
うへぇー、たしかにパッチ本体が消えまくってた。
これは使えるのかな？
URLﾘﾝｸ(mail.gnu.org)

244:243
04/01/14 18:09 PPoiLiAT
あと、これはどうだろう。/linuxしか読めないみたいだけど。
URLﾘﾝｸ(handhelds.org)

245:243
04/01/14 18:13 PPoiLiAT
handhelds.orgだからiPAQとかのbootloader用だった...
逝ってきます

246:login:Penguin
04/01/14 19:09 9ly0Tz8R
>>229
お前頭いいな

247:242
04/01/15 18:32 uQxr1hzR
>>234-245

thx!
243の方は（良くわかんないけど）使えるかもしれませんね。
良く見つかりましたね。ほんと、どうもです。

> handhelds.orgだからiPAQとかのbootloader用だった...
> 逝ってきます

逝かないでぇ～(w

248:login:Penguin
04/01/15 21:55 V9o0EJXO
とにかく最速はReiserFSでおＫですか？

249:login:Penguin
04/01/15 22:04 QiFNLW4c
>>248
HPFSだと何遍言わせれば気が済むんだ

250:login:Penguin
04/01/15 22:05 4egVvEVr
/boot ext3
/ XFS
/usr reiserfs
/home reiserfs
がベスト？

251:login:Penguin
04/01/15 23:16 KRgUttvR
>>249
またまたご冗談を

252:login:Penguin
04/01/15 23:20 NJd3Ve6+
>>250
個人で使うなら、
/ reiserfs

でいいだろ。

253:login:Penguin
04/01/16 00:28 qy7OH5Rm
>>250
メモリの無駄だろ。

254:login:Penguin
04/01/16 00:38 QuRZX7WI
>>252
禿同

というより>>253の指摘もあることだし/bootはext2/3、それ以外はケースバイケース(ただしどれか一種類)
でいいんじゃないかな

時に今Reiser4はどうなっているんだろと言ってみるテスト

255:login:Penguin
04/01/16 00:41 nN0iqQgC
>>254
ReiserFS4がインストールから使えるdist.ってある？

256:login:Penguin
04/01/16 01:54 QuRZX7WI
>>255
むしろ模索中

要はパッケージとインストーラーにreiser4progsが組み込まれ、かつKernelにReiser4サポートが
組み込まれる(あるいは組み込める)のが最低条件なんだが

確か今のところReiser4はオフィシャルのKernel2.6でもまだ試験サポートですら組み込まれてないので、
ディストリ側が独自にパッチを当てない限り上記の最低条件は満たされない

ただGentooのebuildにreiser4progsが上がってたりするので、実は案外その日も近いのではと期待
とはいえ当分は人柱だろうが

長々とスマソ

257:login:Penguin
04/01/16 02:12 OOYyGeYN
snapshotの最後の日付が12月23日だし。
来年辺りになりそうな悪寒。

258:login:Penguin
04/01/18 17:38 pjQhPFTY
Linuxファイルシステム技術解説（6)マダ～？

259:login:Penguin
04/01/18 22:35 2gI2nG1s
>>258
あれだけしかatmarkitではよんでないな

260:login:Penguin
04/01/19 21:46 6oFXilNB
ルートファイルシステムに cramfs を使ってシステムを作っているのですが、
devfsd が起動するときに

"VFS: busy inodes on changed media.."

というメッセージを吐きます。
これは inode が busy っていったいどういう意味なんでしょうか？
ファイルがオープンされているって事？

ルートファイルシステムを ext2 でつくったものをリードオンリーにして起動してみると
上のメッセージは現れません。
cramfs が inode の情報を削っていることが何か関係あるのかな？
今のところ、一応ブートもするし、特に困った症状も出るわけではないのですが
どうも気になります。

何かヒントをお持ちの方、教えてくださいませ。

尚、debian woody で kernel 2.4.18 を使っています。
また、諸事情により /boot だけはext2でマウントしています。

261:260
04/01/19 23:16 6oFXilNB
自己レスです。

kernel source code を grep してみたら、
"VFS: busy inodes on changed media.."
っていうメッセージは
fs/devfs/base.c
の中の関数 check_disk_changed で吐き出されるものでした。
関数説明のコメントを見ると
Check if a removable disk was changed.
ということです。
システムが入っているメディアはCFなんですが、
抜いたりしてないんですけどねぇ。
# 普通しませんよねそんな怖いこと(w

もうちょっと、ちゃんとsource読んでみます。

262:login:Penguin
04/01/20 00:47 lT02LlPa
>>254-257
去年12月のlkmlより
URLﾘﾝｸ(kerneltrap.org)

レイザー本人はものすごい乗り気で、
「version3よりずっと早く安定するだろう、今すぐ experimental でマージできる」
「1月には何らかの成果をおくるよん」としごく楽観的。
対してメンテナは様子見を決め込む。
モートンタソはmmに取り込む意志アリ、みたいな模様。

263:login:Penguin
04/01/20 03:24 0z974ZZ+
ライザーだろ。

264:login:Penguin
04/01/20 03:57 3Um4gj7s
>>262-263
ドイツ人とアメリカ人の喧嘩が始まりますた。

265:login:Penguin
04/01/20 04:36 dhjbo/R1
www.atmarkit.co.jp/flinux/rensai/fs05/fs05a.html

カーネル2.5から取り込まれてるんじゃないの？reiser4

266:login:Penguin
04/01/20 06:51 W9GzXR61
>>262
情報ｻﾝｸｽｺ

>>265
そういう話もあったけど現に2.6.1の時点ではまだexperimentalにすらなってない

267:login:Penguin
04/01/20 22:34 Bu1XSs5p
262のリンク先見てると取り込むの2.7でいいじゃんって言ってる人もいるし。
まぁ、俺はXFSが安定してるからReiserはいまさら使う気ないなぁ。

268:login:Penguin
04/01/20 23:10 S6RrkEKp
>>267
XFSいい？
最近ファイルが多くなってきてlsするのですら重くなってきたから使用してみようかな。

269:login:Penguin
04/01/20 23:49 o616B3x5
1つのディレクトリに数万以上のファイルがなければ違いなんてないでしょ。

270:login:Penguin
04/01/20 23:57 S6RrkEKp
>>269
数万以上でないけど、何百でも微妙に重いような。
感覚的に。

271:login:Penguin
04/01/21 00:23 xOEXzQCM
別に正確に調べたわけでもなんでもないけど、私の経験ではext3 xfs jfs いずれも
クラッシュした後にOSが起動しなくなるとかXが起動しなくなるとかの災難に見舞われたことがある。
で、Reiserfsだけは今のところこういう事態が発生したことはない。ｌ
というわけで何となくReiserfsを使ってます。
実際、デスクトップ用途ではどれがいいんだろう？解説とか見てもあんまり分からないんだよなー。

272:0xdeadbeaf
04/01/21 00:37 5QL6xAgQ
>>271
ext2

273:login:Penguin
04/01/21 01:22 U1Ahe95q
>>272
そうなの？

274:login:Penguin
04/01/21 02:07 o5q0YjjL
>>271
Linuxファイルシステム技術解説
URLﾘﾝｸ(www.atmarkit.co.jp)

これが参考になると思うけど。

275:login:Penguin
04/01/21 09:42 KkTx0o+F
ufs2ﾏﾝｾｰ
DIRHASHﾏﾝｾｰ
softupdatesﾏﾝｾｰ

276:login:Penguin
04/01/21 10:01 qdtutTgQ
>>275
FATじゃダメでつか？

277:login:Penguin
04/01/21 10:09 b7WSV8zK
>>276
使ってもいいけど、お金払ってください。

278:login:Penguin
04/01/21 10:11 +/qC1coM
>>275 奥山健一降臨?

279:login:Penguin
04/01/21 10:59 V78V59zJ
>>271
安定してからのext2, xfs, ext3しか使ったことないけど、crashしたことなんてないよ。
ext2な/がumount出来なくなるくらいだ。

一体何台くらい運用しているとそんなに何回もcrashするの?
Crash後、hard diskのsurface checkやってる?

280:267
04/01/21 20:30 mwLMGUSd
>>271
XFS-1.0のリリース前のバージョンはファイルをオープンしたまま
システムがフリーズするとファイルが壊れたりしたけど、
今は当然のごとくそんなことないよ。

逆に昔のことを考えるトReisefsはバージョンの変わり目が怖い。

281:login:Penguin
04/01/22 00:20 /t3jnhnT
(´-`).｡ｏＯ(このスレでは何回同じ話が繰り返されるんだろう)

282:login:Penguin
04/01/22 00:50 p1HE2PFT
reiserfs(linux-2.4.23 reiserfs 3.6)でjournal replayして復旧すると、
復旧したファイルの中身が壊れるのがいまだによくあるんですが、
何が悪いんでしょうか? notailオプションはつけてます。
データ本体がずいぶん長時間バッファリングされてる気がするんで、
仕方ないのかな。ひょっとしてreiserfs userの常識はsync mount？

283:login:Penguin
04/01/22 02:18 HoikG5hp
というか、meta data以外はねえ

284:login:Penguin
04/01/22 20:05 dnRLj+Fo
フルジャーナルじゃないんだから、
ファイルシステム的におかしくなければ、問題ないんでは？

285:login:Penguin
04/01/27 19:49 cu3YpE5X
>>280
禿同

286:login:Penguin
04/01/28 00:11 faNgctqd
1GBくらいのファイルをランダムアクセス（読みも書きも）する場合って、どのFSが高速ですか？
具体的には、データベースのデータファイルを置く用途を考えているんですが、
この際、信頼性は無視して高速なものを選びたいのです。

287:login:Penguin
04/01/28 00:16 MRFTQRhf
tmpfs

288:login:Penguin
04/01/28 00:19 xe6Wff5r
マジレスでXFS

289:login:Penguin
04/01/28 00:53 8oPPL+iP
FAT32

290:login:Penguin
04/01/28 00:54 wh6gmSGK
rawデバイス

291:286
04/01/28 15:51 V6ophZYk
EXT2とEXT3とRaiserFSは試したのですが、断然EXT2が速かったんですよね。
XFSとFAT32は環境がないので試してないのですが、機会を見てやってみます。
結局のところ、シンプルで余計な処理をやっていないものが速いと考えていいんですよね？
とするとFAT32とかMINIXあたりが最速なんでしょうか。XFSはどうなんでしょう。

292:login:Penguin
04/01/28 17:41 zVYMVK29
まぢれすすっとFAT32は遅い

293:login:Penguin
04/01/28 21:54 yS8KR3k8
>>291
> 結局のところ、シンプルで余計な処理をやっていないものが速いと考えていいんですよね？

脳みそが旧石器時代だな。

294:login:Penguin
04/01/29 01:28 6HYeGcSa
>>293
でもですよ、EXT3よりEXT2の方が速いという事実からすると、ジャーナリングの仕組みが
パフォーマンスの観点から言ってマイナスなわけですよね。バッファリングをちょっぴり
賢くやっているという記事も見掛けますが、ランダムアクセスが多い場合はあんまり役に立って
なかったりすると思うのです。
「小さいファイルを効率良く扱える」とか、「大きいディレクトリを効率良く扱える」といった
特長が新しめのFSには多いと思うのですが、「大きいファイルのランダムアクセスを効率良く」
という特長を備えるものはないのでしょうか。

295:login:Penguin
04/01/29 01:55 Gl5X0xl3
tmpfs

296:login:Penguin
04/01/29 02:03 DAIPqM0S
>>294
機能を後付けされたものと，最初からその機能込みで開発されたものを同列で考えられても…

大きいファイルの扱いだったらXFSは悪くないんじゃないだろうか．
もともとSGIのWSとかで使われてたわけだし．

あくまで想像だけど

297:login:Penguin
04/01/29 02:36 V9Kbp6Jg
>>286 とりあえずカーネルが2.4か2.6からぐらいは決めてふってくれ。
あと信頼性無視ってのは以下のどれ？
・システムクラッシュ後にファイルがこわれてもよい
・ファイルシステムが枯れてなくてシステムクラッシュしてもよい

298:login:Penguin
04/01/29 02:39 +a9YnfXn
>>297
後者はありえないだろ。

299:login:Penguin
04/01/29 02:48 Ay69r0Dr
【XFSについての理解を深める】
URLﾘﾝｸ(www-6.ibm.com)
URLﾘﾝｸ(www-6.ibm.com)
URLﾘﾝｸ(www.sgi.co.jp)
URLﾘﾝｸ(www.linux.or.jp)
URLﾘﾝｸ(www.hiemalis.org)
URLﾘﾝｸ(www.hiemalis.org)
URLﾘﾝｸ(miyagino.homeip.net)

300:login:Penguin
04/01/29 03:06 mAPO9BGU
DBで使ってfs周りでの処理はなるべくさせなくないっていうのなら、
DBMS次第だけど>>290のいうようにraw device使うべきだな。なぜか
スルーされているけど。

せっかく、商用DBMSのためにサポートされた機能でもあるんだし。

301:login:Penguin
04/01/29 03:22 JZqygzJd
>>298
わざわざ無視っていう単語使ってるくらいなんだからわかんないだろ。

302:294
04/01/29 09:13 yy12Q3Y/
>>297
前者です。ミッションクリティカルなものではないので、バックアップからレストアすればいいと
思っています。

>>299
情報ありがとうございます。一通り読んでみます。

>>290
raw deviceって使ったことないのですが、単一のファイルをマウントするような機能なんでしょうか。
あ、とりあえずググってからまた来ます。

303:login:Penguin
04/01/29 09:28 XcLTfiQd
raw device → partitionをfileの様に使う

304:login:Penguin
04/01/29 09:28 XcLTfiQd
あ、block deviceの場合ね。

305:login:Penguin
04/01/29 09:48 XmkIzTiI
一般のFS上でDBMSを使う場合のデメリットは、
DBMSの整合性維持がFSの整合性維持によって、キャンセルされる可能性があること。
大した問題ではないかもしれないけど、二重にフラグメンテーションがおきること。

306:login:Penguin
04/01/29 10:27 nnW0WGXt
なんかいわゆるDBの話をしてるヤシが多いが、1GBのファイルのランダムアクセスというのはマルチメディアストリーミングとかの用途だったりしないか?

307:login:Penguin
04/01/29 23:51 +Jgg7jbO
>>286
＞具体的には、データベースのデータファイルを置く用途を考えているんですが、

308:294
04/01/30 01:49 N9WCO9Fd
XFSの記事（>>299）を読んだらよさげな気がして来ました。試してみます。
raw deviceに関してですけど、mySQLだと使えないっぽいですね。
ところで、kernelは2.4を使っています。
2.6だとI/Oが効率化されるような記事も見掛けますが、XFSを使うとして、その恩恵は受けられる
のでしょうか。
、、、質問ばかりですみません。

309:login:Penguin
04/01/30 16:11 /CwqrzXj
つかうだうだ悩んでないで100GのHDD10分割して主要なFS全部試してみたらいいのに。
んで結果をここで発表すれ。

310:login:Penguin
04/01/30 17:16 /tPt8jzW
>>309
それじゃﾃｽﾄにならんだろ。外周と内周は同一条件じゃないぞ。

311:login:Penguin
04/01/30 17:55 EBhY2INl
10分割がダメなら10台使えばいいのに

312:login:Penguin
04/01/30 23:28 3Kudd6VH
結局どれを使っても大差はでないってことでファイナルアンサー？

313:login:Penguin
04/01/30 23:45 wyinJ7Qw
>>311
一台で順番にやれよ。

314:login:Penguin
04/01/30 23:47 wyinJ7Qw
>>312
大きいファイルのアクセス、FATは遅いよ。
まあFATにする馬鹿もおらんだろうが。

315:login:Penguin
04/01/30 23:48 tMyuANhS
MySQLでも、innodbならraw device使えるだろ

316:login:Penguin
04/01/30 23:54 pjFIkMlh
次世代WindowsではFSとDBが統合されるけどな。
ここでもLinuxは大きく遅れとるな。

317:login:Penguin
04/01/30 23:55 UOX25sNB
釣りは他所でどうぞ

318:login:Penguin
04/01/31 14:30 bCETGydb
FSに履歴が復活してほしい

319:login:Penguin
04/02/01 09:59 g4LjCTRN
XFS1.3.1をSOFT RAID5で使っていると細かいファイルを大量にread/writeしてると
時々ファイルシステムがシャットダウンしてしまいます。
再現できずに苦労しているんですが、同じような経験した人いますか？

320:login:Penguin
04/02/02 04:41 VZWNo0Sg
ファイルシステムがシャットダウンて何?

321:login:Penguin
04/02/02 22:40 zGFFvSVg
>>320
>XFS1.3.1をSOFT RAID5で使っていると細かいファイルを大量にread/writeしてると
>時々ファイルシステムがシャットダウンしてしまいます。
謎ｗ

322:login:Penguin
04/02/05 21:13 s7goLrE+
XFS は突然シャットダウンくらうと
オープンしてるファイルが完全に破壊される。
あんなもん恐くて使えるか。

323:login:Penguin
04/02/05 21:15 lu5ETU54
嘘はやめなさい。
ロールバックすることはあるけどね。←sync使わない限りどのFSでも起こりえる。

324:login:Penguin
04/02/05 22:29 fGdITOXc
昔の話をしてる奴が居る

325:login:Penguin
04/02/06 12:40 VRzAvYFv
>>315
ですな。
URLﾘﾝｸ(www.mysql.com)
InnoDB stores its tables and indexes in a tablespace, which may consist
of several files (or raw disk partitions).

URLﾘﾝｸ(www.mysql.com) には
You can also use raw disk partitions (raw devices) as datafiles. In some
Unixes they speed up I/O. See the manual section on InnoDB file space
management about how to specify them in `my.cnf'.
とある。

326:not 322
04/02/07 07:38 qpf2stI0
>>323
昔の話ですな。
XFS pre1.0くらいのころはファイルをオープンしているときに
システムがフリーズするとファイルが壊れたりした。

まぁ当時カーネルも2.4.5位だったから全てXFSのせいでは
なかったけどね。

いまはそんなことはないよ

327:login:Penguin
04/02/07 07:57 WFqhcBrm
ロールバックは変更が反映されないってことだけで、破壊とは意味が違うだろ。

328:login:Penguin
04/02/08 16:39 1NWJV+8i
どっちやねん。

329:322
04/02/08 23:57 G7QBDDGw
昔といっても gentoo が出てしばらくたったぐらいの話。
そしてロールバックではなく「完全破壊」です。
XFS こえーよ。あんなのは他のファイルシステムではなった事がない。

330:login:Penguin
04/02/09 00:16 YphTwcDO
完全って何よ? 物理フォーマット?
あ、返事しなくていいから。どうせ(ry

331:login:Penguin
04/02/09 00:17 YphTwcDO
>>328
どっちやねんって、ロールバックは健全性は保たれている。
破壊って言ったら普通は健全性が損なわれている。

332:login:Penguin
04/02/09 00:37 sC3Zk+Ez
2.6.3-rc1カーネルなDebian sidでnavi2chしていたらカーネル固まった。
他所からping打っても返事無し。リセットした。
XFSなファイルシステム自体は壊れなかったけど、
~/.navi2ch/pc.2ch.net/linuxの下のほげほげ.datなファイルの中身は
グチャグチャになってしまった。
ext3の頃はそんな事なかったんだけどねー。
2ちゃんねるから足を洗ういい機会かもしれない、とは思った。

333:login:Penguin
04/02/09 00:40 XpgIuwzN
XFS信者キモイ。

334:login:Penguin
04/02/09 08:16 4YInUGD9
つーかすぐ信者論争起こしたがる考えがわからん。

335:ヽ(´ー`)ノ
04/02/09 14:20 xneU89ut
>>332
~/.navi2ch の下がゴチャゴチャになったのはファイルシステムは
関係ないと思うんだが。変な終わらせ方したらたまになる。

336:login:Penguin
04/02/09 15:31 jPSJguiG
Reiser信者は絶滅したのですか？

337:login:Penguin
04/02/09 15:32 jPSJguiG
おおくまさんXFSの具合いはどうですか。
おおくまさんさやかタンの具合いはどうですか。

338:login:Penguin
04/02/09 18:13 M16SWX6N
>>330
言いたい事あるならはっきり言えば？
なんでも「（ｒｙ」にすればいいと思ってるでしょうかこの人。
リアルで語尾がうやむやになって聞きとりにくいタイプ？

339:login:Penguin
04/02/09 20:51 GhmEabJe
>>330
じゃあ、使い方が悪いのかもね
2年以上使ってるけど特に問題ないよ

340:login:Penguin
04/02/10 00:24 J64RHnv6
>>337
なつかしいな。

341:login:Penguin
04/02/10 23:14 2jfAUvMX
XFS 信者マダー？

342:login:Penguin
04/02/11 00:28 EZiXYSs+
>>341
大して使ってないのにXFSを勧めてる連中が何人も登場した気がするが、それでも不足ですか？

343:login:Penguin
04/02/11 00:42 Qn2GrHtv
自演クサ！

344:login:Penguin
04/02/11 07:05 rQjsSvx6
IRIX使ってるけど、ハードディスクがやたら五月蝿い。
これってXFSのせいかな？

345:login:Penguin
04/02/11 08:27 6S9jTgap
そういや、294は結局どうしたんだ?

346:login:Penguin
04/02/13 03:45 ayNMDy6b
reiser4、今月の六日に更新されてんな。

347:login:Penguin
04/02/14 07:43 kX0ZpYOB
どのファイルシステムでもsysctlのvm.bdflushでダーティーページ
の書き込みタイミングを調整すると書き込み時の応答性や信頼性
が調整できるよ

348:login:Penguin
04/02/14 12:58 Nk6dZisG
ext3に圧縮機能は無いですか？
透過的な圧縮機能があればいいのになぁ、と思っているんですが。

349:login:Penguin
04/02/14 14:55 SxenY+uM
>>348
NTFSならありますよ。便利ですね。

350:login:Penguin
04/02/14 15:02 Nk6dZisG
>>349 いやまぁそれはわかってはいるんですが…

351:ヽ(´ー`)ノ
04/02/14 15:09 QjBE5SxX
>>348
とりあえず Google ぐらい使えよ、と言いたいわけだが。

352:login:Penguin
04/02/14 15:17 zgL8ZkS5
>>347
どっかで実験レポートだしてる？
vm.bdflushはジャーナル書き出しのタイミングは調整できないと思うし、
XFSのリアルタイムサポート(?)もこれじゃいじれないよな。
やれることには相当限界がありそうな気がするんで。

353:login:Penguin
04/02/14 17:22 vUtx4NfM
>>348
もう少し待ってよ。
今作ってるから。

354:login:Penguin
04/02/14 19:14 CeFOFhMA
e2compr、ext3につかえっかな

355:login:Penguin
04/02/14 19:24 SxenY+uM
NTFSのソースコードは流出しなかったようですね。残念ですね。

356:login:Penguin
04/02/14 21:07 Nk6dZisG
>>355 流出していたら、かなりおいしかったはず。

357:login:Penguin
04/02/14 22:53 EVeEM0ap
SCOがUnixWareにNTFSサポート組み込めてたらもっと売れてたかねえ？

358:login:Penguin
04/02/14 22:55 zinZCNqj
つーか、CIFSなら流失して欲しかった。
NTFS今更どうでもいい。読み書きできるし。

359:login:Penguin
04/02/15 20:29 XK+NE1xY
逆にNTFSが流出したら潰されそう

360:login:Penguin
04/02/29 03:01 hLQBw/Mk
NTFS の write サポートって
2.4系にバックポートされないのかな？
2.4.25だとDANGEROUSのまま

361:login:Penguin
04/02/29 03:47 w+DnpQFE
URLﾘﾝｸ(linux-ntfs.sourceforge.net)
これだろ？
2.6でDANGEROUSの表示が消えたのかどうかはしらんが、
書き込みが安全だと言い切れる状態ではない。

362:login:Penguin
04/02/29 04:38 LCUm+YYA
ｵﾌﾟｿ厨ってソースが無いものに対してはまったく無力だな。

363:login:Penguin
04/02/29 09:41 bgzDDfYK
>>362
まあそういうもんだろ
無力なやつはほっておけ

364:login:Penguin
04/02/29 18:20 W6jQgk9B
またドザか。

365:login:Penguin
04/03/04 06:55 2rvYzD4v
kernel 2.4 で ext3 を ordered で使ってるのですが、
大きなファイルを書き込もうとすると
5 秒経つごとに kjournald が数秒間激しく走って、
他の処理がストップしてしまいます。
いくら何でも遅すぎという気がするのですが、
そういうものなんでしょうか。

366:login:Penguin
04/03/04 15:36 ikN/Tr9S
reiserfs から reiser4fs にうpしたいんだけど

367:login:Penguin
04/03/05 01:13 eRm/fC7Z
>>365
そんな印象はないが…何を実験したらそう感じる?

368:login:Penguin
04/03/05 20:07 2MEpwOYP
実験というか、普通に 100MB ほどの file cp してるだけで……
RHL8 をベースに kernel とか自前で compile してる環境で、
あんまり素性は良くないとは思いますが……

369:login:Penguin
04/03/05 21:03 xuooe8hw
俺のヘボ環境(PentiumII 400MHz + memory 256MB)で、
IEEE1394外付けHDDで100MBのファイルをローカルコピーした所要時間は
$ time cp xaa test
cp xaa test 0.04s user 3.16s system 24% cpu 12.896 total
だった。もちろんディスクアクセスはバリバリ言って
kjournaldがtopの2番目(1番目はもちろんcp)になったりはしたが、
他の処理がストップって感じじゃないぞ。他の処理って何？
ひょっとして100MBのファイルを何個もガチンガチンさわるような仕事？

370:login:Penguin
04/03/06 00:46 viX8hVA9
tume cp a b して
0.490u 18.300s 0:35.23 53.3% 0+0k 0+0io 98pf+0w
と出ましたが……
裏で他に重いプロセス動いていない状態で cp だけしましたが……

371:370
04/03/06 00:51 viX8hVA9
IDE HDD二つあって、両方で time で同じような数値がでてるから、
ハードの故障ではないと思うのだけど……

372:login:Penguin
04/03/06 16:49 Wbl/ELNq
システム50%使って35秒…俺よりスペック下？
(1) hdparm -t
(2) time dd if=/dev/zero of=./b ibs=1024 count=100000
(3) time dd if=./a of=/dev/null ibs=1024 count=100000
はどうなる？まさかsync mountだとか？

373:login:Penguin
04/03/07 08:24 rvQsV/pc
お付き合いいただいてありがとうございます。
CPU は Pen3 の 800MHz です。結果は上から順にこうなりました。

Timing buffered disk reads: 64 MB in 14.53 seconds = 4.40 MB/sec
1.090u 9.740s 0:23.99 45.1% 0+0k 0+0io 140pf+0w
2.670u 15.200s 0:22.35 79.9% 0+0k 0+0io 140pf+0w

374:login:Penguin
04/03/07 09:38 rvQsV/pc
syncで、で思い出したので調べてみたら、
DMA転送が何故かoffになってました……
原因はよく分からないのですが、
とりあえず起動時にhdparm -d1を実行して様子をみます……

375:login:Penguin
04/03/11 22:45 M5DTqQsJ
質問です。

カーネル2.6使用時のファイルシステムは，現時点で何が一番オススメでしょうか。
ディストリビューションはDebianで，
マシンの利用目的はWebサーバです。
できればACLも試してみたいと思っています。

376:login:Penguin
04/03/11 22:56 WJ5hr95y
xfs

377:login:Penguin
04/03/11 23:02 EpkHQQD1
ext2

378:login:Penguin
04/03/12 15:43 CDHj/mtN
どこに書けばよいのかよくわからなかったのでファイルシステムスレにて失礼します。

Linux で、ローカル・ディレクトリ・チェックポイントを実現するようなファイルシステムは存在するのでしょうか？
ローカル・ディレクトリ・チェックポイントとは、NetFORCFE NAS サーバーに実装されているようなものです。
URLﾘﾝｸ(www.tgi.co.jp)
URLﾘﾝｸ(www.tgi.co.jp)

379:login:Penguin
04/03/12 15:48 W69aggCM
>>378
LVMのスナップショットみたいなもん？

380:login:Penguin
04/03/12 16:00 ++M80f7W
ならこっちかな。

LVMを語らせていただけませんか？
ｽﾚﾘﾝｸ(linux板)

381:login:Penguin
04/03/12 18:20 CDHj/mtN
>>379 >>380
謝謝！まさにそんな機能でした。

382:login:Penguin
04/03/12 18:33 3s8oHFYh
質問です。

まっさらから Debian 3.0 を kernel 2.4 で新規インストールするという前提で、HDD 2基を
マウントする Linux マシンを組みます。
HDD_1 はシステム、アプリ、/var や swap などが入り、
HDD_2 は完全なファイルサーバー用のエリア（100MB over/file が基本）
とするとき、

HDD_1（のシステム領域）と HDD_2 は、それぞれどのファイルシステムを選択するのが
よいと思われますか？

なお優先順位はどちらとも
　耐障害性 > 安定性 > 速度
です。

383:login:Penguin
04/03/12 23:32 rthV9o/V
>>382
とりあえずジャーナリングできるやつで、あとは好きにすれば?
新しく作るのに今更ext3でもなかろう...とは思うが。

ファイルサーバ用のファイルシステムは、今ならACLに対応したやつがホットかな。

ちなみに、漏れはほとんどreiserfs。
小さなファイルがほとんどだから、xfsよりもこっちを勧められた。

384:login:Penguin
04/03/13 10:38 DcGhysxg
>>383
すいません。reiserfs3.x から reiserfs4 に上げたいんですけどお教え下さい。

385:login:Penguin
04/03/18 20:49 oingiW5Z
NTFS書き込み正式サポートはまだですか？サポートされればKNOPPIXの利用価値が
激増するんですけど。

386:login:Penguin
04/03/19 22:59 YRFlNFy9
>>385
Captive-NTFS使えば？
URLﾘﾝｸ(www.jankratochvil.net)
KNOPPIX3.4で採用されるらしいよ。

387:login:Penguin
04/03/20 16:18 WZAPoCo5
>>386
ユーザ空間でファイルシステム動かす話で実用化を狙ってるのが地味に面白いんだけど、
これってNTFSドライバはWindowsの純正のをもってくるんだよね？
単に入手方法だけ考えるとCDブートできない機械用にMSが配布してるフロッピから
取ってこれるのかもしれないけど、ライセンス的にどうなのかな。

388:login:Penguin
04/03/20 21:22 x4cMoRse
WinXP_EN_HOM_BF.EXEをcabextractで展開するとcdboot5.imgにntfs.sysが見えるね。

389:login:Penguin
04/03/21 07:29 rJHOQEvY
FATの特許無視して勝手に使ったりドライバファイル盗んで勝手に配布したり
相変わらずモラルを知らない奴らだな。

390:login:Penguin
04/03/21 07:35 5tT6LEFS
>>389
お前FATのライセンス知ってる？

391:login:Penguin
04/03/21 11:46 Pq7pE02T
>>387-388
っつーか、>>386のツールの中にM$のサイトから自動的にダウンロードするソフトが付属しています。

392:login:Penguin
04/03/23 13:36 AG2H318m
>>386
Captiveに手を染めるぐらいなら本家サポートを待ったほうがよさげですね。
2.6.xでは書き込みもdangerouse扱いじゃなくなったんですっけ。

393:login:Penguin
04/03/24 10:06 oq0vBsj1
(´･ω･｀)

394:login:Penguin
04/03/24 11:44 +HppsPhq
>>391
ダウンロード可能＝使用可能じゃないだろ。
しかもユーザーに責任押し付けてるだけだし。
そういうことするから信用がなくなるんだよ。

395:login:Penguin
04/03/24 11:57 HvqBGrKz
>>394
だったら使うなよ

というのがこの業界のスタンスだし
まあいいんじゃないの？

396:login:Penguin
04/03/25 12:24 tZ5tq3DY
FATの特許って、データ構造に対するものなの？
あるいはデータへのアクセス手法？
それとも両方？

教えてエロイ人

397:login:Penguin
04/03/25 12:25 wQXoVoix
VFATのロングファイルネーム対応に対するもの。

と適当言ってみる。

398:login:Penguin
04/03/26 06:03 jS/iKX5x
>>396
両方。

Windowsソースコードの流出、OfficeのフォーマットのXMLでの公開で
MSは自社技術をクローズドソースでは保護できなくなってきている。
なので特許による保護・ライセンスビジネスに方針を転換している。
もうすぐLinuxに対する対応も決まってくるよ。
おそらく会社単位で狙い撃ちしていくことになるはず。

399:login:Penguin
04/03/26 09:17 6xoXy2a2
Windowsソースコードの流出ってそんなに深刻なの？

あとEUにはもっとがむばって欲しい。
Officeのフォーマットはオープンにすべきだ、くらい言ってくれ >EU

400:login:Penguin
04/03/26 10:54 r4Oaasi7
>>398
データ構造で特許ってとれるの？

401:400
04/03/26 10:56 r4Oaasi7
>>398
あと何処の国の特許取ったの？

402:login:Penguin
04/03/26 12:44 rZIDnhWH
>>399
それは既に言っている。
XML schemaの公開を制裁の一部に加えようとしているし。

403:login:Penguin
04/03/26 13:11 5Iq7H9D3
>400

FATの件ならFATのデータ構造で特許をとったわけじゃないよ。
VFATのロング/ショートファイルネーム生成の実現方法に関する特許をMSが
取得している訳。
したがってVFATではなく FAT で8.3形式のファイル名しか利用しないという
制約の元で使用する限りにおいてはMSの特許に触れることはない(はず)。
あと、取得したのは米国の特許ね。
この辺は
URLﾘﾝｸ(www.itmedia.co.jp)
に書いてあるのが詳しいかな。問題の特許の米国特許番号まで載っている。

404:login:Penguin
04/03/26 14:15 rZIDnhWH
デジカメのメモリカードとかVFATだよなあ。儲かりそうだなあ。

405:login:Penguin
04/03/26 15:50 k+o0nQDE
つーかさー、Windowsとデュアルブートして
データ共有領域にFAT使ってるやってるだけでも
有り難いと思えばいいのに。

406:login:Penguin
04/03/26 20:44 zPHssn+4
>>404
デジカメなんかは8.3形式じゃない？
DSCF0001.JPG
とかってなってるよ。

407:login:Penguin
04/03/26 21:09 LghBzjcP
>>406
ありゃあえてそうつけてるだけ

408:login:Penguin
04/03/26 21:32 8l+mmiF8
>>403 あと、取得したのは米国の特許ね

米国以外で使う分には、今のところは問題ないわけ？

409:login:Penguin
04/03/26 21:57 rZIDnhWH
>>406
ディレクトリが、2004-03-26なんてなってるよ。

410:403
04/03/27 00:00 M4lJiMFX
>408

すまん、それは俺には何とも言えない。MSの法務部門がなんというかだな(w
調べてみた限りでは問題の特許は国際出願にはなっていないようだが。
また日本の特許庁のサイトでもちょっと検索してみたが、引っかからなかった
ので日本では該当特許は成立していないと思われ。違ってたらスマソ。

411:sage
04/04/08 19:42 MyiCZN16
(;_;100G over の XFS 使って 100M ～ 200M 前後のファイルを読み書きしていたら、mount も xfs_repair(1) も不可能な状態に ...ext3 使ってて壊れたから乗りかえたのに、いきなりこれかよ ...

412:411
04/04/08 19:46 om+YpLci
間違えて age ちゃったよすまソ

413:411
04/04/08 19:57 MyiCZN16

ちなみに壊れた FS のログはこんな感じ。

> Apr 8 19:00:03 xxxx kernel: Filesystem "device-mapper(254,13)": corrupt inode 167772289 ((a)extents = 107147). Unmount and run xfs_repair.
> Apr 8 19:00:03 xxxx kernel: 0x0: 49 4e 81 a4 01 02 00 01 00 00 00 21 00 00 00 21
> Apr 8 19:00:03 xxxx kernel: Filesystem "device-mapper(254,13)": XFS internal error xfs_iformat_extents(1) at line 678 of file xfs_inode.c. Caller 0xc01ec790
> Apr 8 19:00:03 xxxx kernel: eb4dbd20 c01ecce9 c030e168 00000001 f6b13400 c030e0b4 000002a6 c01ec790

kernel は 2.4.24 に debian sid の
kernel-patch-device-mapper(1.00.07-4) と
kernel-patch-xfs(1.3.1-3) を
あてて使ってる。

mount したまま resize する機能もめあてだったんだが ... < xfs
どうするかな ...

次ページ