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

**login:Penguin** · 2008/10/26(日) 15:18:36

過去スレ
　01 http://pc.2ch.net/test/read.cgi/linux/1006743807/
　02 http://pc5.2ch.net/test/read.cgi/linux/1063025258/
　03 http://pc8.2ch.net/test/read.cgi/linux/1101495293/
　04 http://pc8.2ch.net/test/read.cgi/linux/1136695633/
　05 http://pc8.2ch.net/test/read.cgi/linux/1152348695/
　06 http://pc11.2ch.net/test/read.cgi/linux/1173530292/
07
08 http://pc11.2ch.net/test/read.cgi/linux/1190788761/

**login:Penguin** · 2009/03/14(土) 10:33:27

>>859
ファイルシステムベンチマークなら、bonnie++が定番。

**login:Penguin** · 2009/03/14(土) 10:46:54

これってext3でも起こるよね。起こりにくいだけで。
>>863の最初の例なんか、
truncate -> writeで、write前に落ちれば
どのジャーナルモードでもデータが消えるんじゃないか?
すでに実行されていたとしても、ジャーナルにあって次マウントしたときにreplayされても。

**login:Penguin** · 2009/03/14(土) 11:40:29

＞ rename("~/.kde/foo/bar/baz", "~/.kde/foo/bar/baz~") --- this is optional
＞ rename("~/.kde/foo/bar/baz.new", "~/.kde/foo/bar/baz")

は

unlink("~/.kde/foo/bar/baz~")l
link("~/.kde/foo/bar/baz", "~/.kde/foo/bar/baz~")
rename("~/.kde/foo/bar/baz.new", "~/.kde/foo/bar/baz")

にすべきだよな

**login:Penguin** · 2009/03/14(土) 14:45:40

>>865
最初のはそうだけど、２つ目が問題なんだわ。

xfsはデフォルトでメタデータが先にコミットされるので、その直後に
クラッシュするとファイルシステムの構造的には不整合はないが、その
メタデータが指しているデータは存在しない。

で、xfsはメタデータがゴミデータを指してる状態で開けると、何が
見えるかわからん（古い/etc/passwdのブロックかもしれん）から
セキュリティ的な問題があるよね、ときちんとメタデータが指している
データを最初はゼロクリアした状態にしている（本来のデータがコミット
されたら当然そちらに付け替える）。

ext3等はデフォルトではデータが先にコミットされるので、２での問題は
生じ得ない。一方、xfsの順序は最高性能を発揮するためで、生まれた時代や
背景を考えると致し方ない。

POSIX的にはfsyncしてない限り、どちらの挙動も問題なしで、fsyncしない
アプリ開発者がPOSIXを理解してないというのが結論になる・・・が、
正直２の書き方って、すごい一般的だよね、さあどうしよう、という状況。

　hogehoge > fugafuga && fsync fugafuga.new && mv fugafuga.new fugafuga

とか直していくしかない。Ubuntuだっけ？にfsyncコマンドがあるのは
このためだろうと思われる。

もっとも、ドライブキャッシュがあるとfsyncすら保証してくれないので、
さらにバリア張らないととか延々と話が続くんだけど。

**login:Penguin** · 2009/03/14(土) 16:28:12

blogの翻訳？

**login:Penguin** · 2009/03/14(土) 19:12:33

一時ファイルに書き込み→名前変更ってのは当たり前の技法だと思ってたけど
そうでもないのかな？

**login:Penguin** · 2009/03/14(土) 20:08:40

>>869
いや、あたりまえの技法というコンセンサスはとれていた。ゆえにTed Tsoは仕様どおりだ！とか片意地はらずに直すと言っている。という理解

**login:Penguin** · 2009/03/14(土) 20:11:26

しかしまぁ、仕様通りだから悪くない、と言っても汎用的なFSとしては使えないよなぁ

**login:Penguin** · 2009/03/14(土) 20:19:32

でもそうやって理想の仕様よりも現実を優先していくとWindowsみたいになるわけだけだが。
一見すると謎仕様すぎて、分かってない連中にボロくそに言われるという。

**login:Penguin** · 2009/03/14(土) 20:21:09

>>867。
なるほど。
>>869もいってるけど、うまく書けたらリネームっていうのは、良くやるやり方なので、
確かにext3の挙動の方が安心できる気がしますね。

結局ext4での書き込みがext3より大幅に遅延するとしても、
ジャーナルに記録されていれば大丈夫な気がするのだが。

**login:Penguin** · 2009/03/14(土) 20:23:23

そしてHans Reiser恩赦に

**login:Penguin** · 2009/03/14(土) 21:23:11

壊れたメタデータのコミット先を教えるかわりに
FSの破壊を軽減する司法取引だな

**login:Penguin** · 2009/03/14(土) 21:57:26

ZFSとかFS層の破壊防止を徹底してるから、
これからはそういう設計が定番になるんじゃないかな。

Btrfsはどうなんだろ？

**login:Penguin** · 2009/03/14(土) 23:59:37

super_operations構造体のメンバ
freeze_fsやunfreeze_fsってwrite_super_lockfsやunlockfsから名前変えたのか？何故に・・

**login:Penguin** · 2009/03/15(日) 10:02:11

>>872
これは現場ではうまくいっていたけど理想的な方法ではないのを、改めているのだと思うぞ。

**login:Penguin** · 2009/03/15(日) 10:18:44

>>877
きまぐれ。

**login:Penguin** · 2009/03/15(日) 19:42:41

もう名前変更しなくていいようにメンバは

　struct struct0001_s {
　　member0001_t member0001;
　　member0002_t member0002;
　　member0003_t member0003;
　　...

として意味は仕様書と帳票で管理すべし。これならコードで
書く内容も迷うことが少なくていいし、順序がずれたらABI破壊バグと
すぐわかる。

**login:Penguin** · 2009/03/15(日) 20:01:52

>>879
だったら　やめて　ちょうだい
本気で好きになりそうだから
あなたの前では　きれいでいたいし

**login:Penguin** · 2009/03/15(日) 20:31:39

>>876
btrfsはZFSと同じくCOWで書くから、この問題は起こらない

**login:Penguin** · 2009/03/15(日) 20:34:14

btrfsはなんでaddressingを128bitにしなかったの？ZFSに負けちゃうよ

**login:Penguin** · 2009/03/15(日) 20:56:32

>>881
吹いた

**login:Penguin** · 2009/03/15(日) 22:13:07

デ♥フ♥ラ♥グ

**login:Penguin** · 2009/03/15(日) 23:37:34

>>884
歌詞の一部です　若かった昔を思い出させる
今夜のナンバー　１曲目は
長渕剛　素直
ttp://www.youtube.com/watch?v=cM-QvJI_RJQ

**login:Penguin** · 2009/03/16(月) 01:59:21

>>883
btr2fs誕生のフラグです

**login:Penguin** · 2009/03/16(月) 02:03:51

>>883
アドレスが128bitだとIPv6を連想して不吉だから

**login:Penguin** · 2009/03/16(月) 15:19:00

マジレスするとVFSが対応していない。

**login:Penguin** · 2009/03/16(月) 15:31:04

ext3は罪な奴だな
fsyncを徹底すると遅すぎて使い物にならないし
fsyncをしなくても十分安全だから
fsync無しの更新を一般化させてしまった

ext4も、data=orderedがデフォルトで安全なはずなんだけどなぁ
遅延アロケーションはジャーナルのコミットを考慮しない言うのか

**login:Penguin** · 2009/03/16(月) 16:49:59

extなんとかが最もポピュラーなのはなぜ？
歴史的な理由ですか？

**login:Penguin** · 2009/03/16(月) 18:13:10

なんだかんだで愛されてるんだよ

**login:Penguin** · 2009/03/16(月) 18:59:45

殺人よりはマシだからな（ワラ

**login:Penguin** · 2009/03/16(月) 20:55:40

>>891
そのとおり。
ext2時代は事実上、それしか選択肢がなかった。
ext3時代はredhatが他のFSをサポートしなかった。FSの品質はテスターの数にめっさ依存するので
ディストロの対応重要。

**login:Penguin** · 2009/03/17(火) 03:29:17

Don’t fear the fsync!
http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/

**login:Penguin** · 2009/03/17(火) 09:33:29

教祖様は極東の言語でしか、お言葉を賜らないからなぁ。
lkmlやfsdevelでも議論を見たことがないし、
T'soのblogにコメントでもしてほしいぜ。

まぁ、下々のページにいちいちコメントなんてつけないか。

**login:Penguin** · 2009/03/17(火) 10:39:55

from Japanじゃなくてfor Japaneseの教祖様だから仕方ない。

**login:Penguin** · 2009/03/17(火) 10:59:40

数年前にLKMLで見たような記憶があるが。

そーいやDOUBTはどうなったのだろう？

**login:Penguin** · 2009/03/17(火) 11:06:54

ttp://slashdot.jp/linux/article.pl?sid=06/07/11/0839251
ttp://devresources.linux-foundation.org/dev/doubt/
便所の落書の域を出ることなく終わったな

**login:Penguin** · 2009/03/17(火) 19:54:49

okkyって言えば↓やってみた奴っている？
http://slashdot.jp/~okky/journal/469580

速くなるかなと思ってうちのOCZSSD2-1VTX250Gで試してみたけど
普通にmkfs.ext4したのと比べて速くなったような気がしないんだよな
つか、買ったばっかのSSDだからあんまり過酷なテストとかしたくもないしw

**login:Penguin** · 2009/03/17(火) 20:42:34

>>900
ttp://mkosaki.blog46.fc2.com/blog-entry-833.html
ttp://tytso.livejournal.com/60368.html

**login:Penguin** · 2009/03/17(火) 22:41:41

>つか、買ったばっかのSSDだからあんまり過酷なテストとかしたくもないしw

ならやんわりテストすればよろし
びみょーに寿命は伸びると思うよ

**login:Penguin** · 2009/03/18(水) 03:18:16

>>900
ext4だと強烈な遅延書き込みになっているからじゃない?

**login:Penguin** · 2009/03/18(水) 03:29:17

↓のスレでHAMMER FSのBonnie++ベンチマーク取ってくれた人がいたから貼り。
なんかめっさ速くない？

dragonfly bsd どうよ
http://pc11.2ch.net/test/read.cgi/unix/1088515885/

Athlon64x2
メモリ2G
ad4: 953869MB <WDC WD10EACS-00D6B0 01.01A01> at ata2-master SATA150

nohistory: athlon64.x2,300M
------SequentialOutput--------SequentialInput---Random-
-PerChr---Block---Rewrite--PerChr---Block----Seeks--
34257 96 97652 40 71778 14 39591 97 932845 68 13087.0 23
------SequentialCreate--------------RandomCreate--------
-Create----Read----Delete---Create----Read----Delete--
57502 79 130264 99 18240 30 36341 48 123916 94 39858 66

nohistoryなし: athlon64.x2,300M
------SequentialOutput--------SequentialInput---Random-
-PerChr---Block---Rewrite--PerChr---Block----Seeks--
32760 85 96287 15 71640 17 39757 98 928711 59 49945.1 85
------SequentialCreate--------------RandomCreate--------
-Create----Read----Delete---Create----Read----Delete--
60186 91 130592 93 28627 39 64754 89 143084 102 32111 55

**login:Penguin** · 2009/03/18(水) 03:39:53

誰か>>904の人と同じようなスペックの人、
BtrfsのBonnie++ベンチマーク取ってみてくれない？
↓の方法で修正してからmakeよろしく。

http://plaza18.mbn.or.jp/~moriban/linux/UsageOfBonnie.html

果たして ZFS vs Btrfs vs HAMMER の勝者は誰になるのか。

**login:Penguin** · 2009/03/18(水) 04:52:34

ext4なんて今更つかうわけがない

**login:Penguin** · 2009/03/18(水) 07:35:22

>>900
なんかOSの仕組みとして、Windowsと比べてLinuxは
4Kランダム書き込みが少ないんじゃないかな？
VMwareとかでXP立ち上げたりしてると、
ただ単に起動するだけでもスゴい量の書き込みが発生してる。
それに対してLinuxは、書き込みはせいぜいlogとpidと/tmp/ぐらいじゃない？

大量の書き込みが発生するようなデーモン（PostgreSQL、MySQLとか）も、
できるだけまとめてから書き込もうとするから、
4Kランダムよりシーケンシャルが多いような気がする。

細かい書き込みがあるのは、メールサーバぐらい？

**login:Penguin** · 2009/03/18(水) 12:44:49

>>907
かの懐かしいnntpdなんて大量のファイルの読み書きをするサーバの代表だったけど、
今は日本ではほとんど使われてないなぁ。

あとはvirus scanner周りかな。

**login:Penguin** · 2009/03/19(木) 05:04:32

BtrfsのBonnie++ベンチマーク、ググればいくつか見つかるけど、
環境によって結果がバラバラだね。
XFSに勝ってるのもあれば、EXT3に負けてるのもある。
まー、いずれも>>904のHAMMERには勝てないけど。

けど、SSD最適化、FSミラーリング、オンラインFSチェック、
スナップショットとか楽しみな機能盛りだくさん。
Fedora 11の正式版ぐらいまでには、もう少し成熟してくれると良いんだが。

wiki - Btrfs
http://ja.wikipedia.org/wiki/Btrfs

**login:Penguin** · 2009/03/19(木) 10:59:23

BtrfsがXFSに勝つなんてマグレさ

XFSよ永遠なれ

**login:Penguin** · 2009/03/19(木) 13:43:31

HAMMERはいくらZFSというお手本があったとはいえ、開発者がめちゃくちゃ少ない
どマイナーOSだというのに驚異的だね。Linuxが見習うべきところが多々ありそうな。

**login:Penguin** · 2009/03/19(木) 14:08:56

人が少ない分やりたいように出来るんじゃない？

**login:Penguin** · 2009/03/19(木) 20:08:34

俺も自分用のファイルシステム作りたい

**login:Penguin** · 2009/03/19(木) 20:19:23

だれかNILFSの健闘を讃えてやれよ・・・

**login:Penguin** · 2009/03/19(木) 20:28:08

マージされてからが本番です。
feature-removal-schedule.txt に載らないようにしないとね。

**login:Penguin** · 2009/03/19(木) 21:15:09

>>913
FUSEというおもちゃがあるおかげで、
思いついたアイデアを試す敷居は随分と低くなったぞ。

**login:Penguin** · 2009/03/19(木) 21:27:39

>>914
LFSはZFSの登場後、一気に旧世代に追いやられちゃったからなぁ。

NetBSDもLFS開発が止まっていて、いまアクティブに開発されているLFSでは
唯一ということぐらいしか売りにならないし…

**login:Penguin** · 2009/03/19(木) 23:09:40

ZFSは純粋にファイルシステムとしての革新というよりも，
今までのファイルシステムの階層構造をぶち壊してるという意味で
革新的なわけだから，そのレイヤー構造を守ってる
NILFSと直接比較しちゃかわいそうだろ．

**login:Penguin** · 2009/03/19(木) 23:12:24

でも使う側からしたら、一体にしか見えないから比べてもいいんじゃね

**login:Penguin** · 2009/03/20(金) 03:42:25

>>918
そのファイルシステムの階層ぶちこわしってのが
一番使いづらい点だったりするのが惜しい。

**login:Penguin** · 2009/03/20(金) 03:59:58

>>920
そうか? LVMとmdとfsとで機能がかぶっていてなんだこりゃとなっている
現状より、ZFSやHAMMERやBtrfsでまとまっているほうが、アーキテクチャ的にも
ユーザ視点でもすっきりしていると思うが。

**login:Penguin** · 2009/03/20(金) 05:08:54

システムコンポーネントとして粒度が大きすぎるんだよね
入れようとすると総取っ替えになるし、用途に合わせた選択肢はむしろ減るし。

結構前にも同じ事書いたから見るの2度目だったらすまん

**login:Penguin** · 2009/03/20(金) 05:09:32

用途に合わせた選択肢
用途に合わせた構成の選択肢

**login:Penguin** · 2009/03/21(土) 16:11:30

>>904
なんだ、ここでやってたのか。
ところでこの間の結果はSMPカーネルで実行したんだけど、
ちょっと用事があってUPカーネルでも実行したらなんか数字が
半分になったよw これLinuxでも同じ?
athlon64.x2,300M,17625,45,86764,15,65295,10,19007,46,377947,26,60259.2,51,16,65862,81,62441,44,37315,48,23631,25,113010,64,17925,27

**924** · 2009/03/21(土) 16:32:06

ごめん、勘違い。
UPカーネルだからじゃなくて、dnetc動かしてたの忘れて
bonnie++実行してたからみたい。dnetc止めてから測り
直したら前と同じ数字になった。

**login:Penguin** · 2009/03/21(土) 19:14:52

>>921
キレイなアーキテクチャ欲しがるのは理想に燃える(笑)学生くらいなものさ。
機能被ってるなら片方使わなければいいし、被ってるといっても特徴は出るんだから必要な方を選べる。

**login:Penguin** · 2009/03/21(土) 20:25:16

>>926
はぁ?

**login:Penguin** · 2009/03/21(土) 20:33:06

>>927
無能な年寄りほど大人ぶって説教するのが好きなものです。
といって、有能な年寄りは無茶ばっかり言うものです。
というわけで、凡人にとってはどちらも迷惑な年寄りです。

**login:Penguin** · 2009/03/21(土) 21:34:50

あくまで年寄りですからw

**login:Penguin** · 2009/03/23(月) 18:53:52

年寄りがどうこうとか、説教がうんぬんっていうかさ
そもそも話が噛み合ってないから

バカ相手に議論してもしょうがないから、仮にZFSで説明すると
ZFSにはストレージプールの他に、スナップショット、CoW、RAID-Z
といったような特徴があるわけだ

で、LVMやMDをどう組み合わせようが、CoWやRAID-Zは当然使えないわけよ
機能が被るとかいう次元の話ではないんだ
そもそもMDみたいなチンケなSoftwareRAIDとRAID-Zを一緒くたにされてもね…

ましてやLVMやMDを本当に使ったことがあれば、いざという時の復旧の大変さは身に染みているはず
それがストレージシステム上のレイヤのひとつとして全て統一して管理出来るってのに
アーキテクチャがキレイとか、キタナイとか、何を的外れなこと言っているんだか全く

**login:Penguin** · 2009/03/23(月) 21:06:25

そこまで言うなら、なんでクラスタやネットワーク分散まで取り込まなかったのかと
ネットワーク非対応のくせに統一して管理なんて、なんの冗談かと

しょせんZFSやNFSをどう組み合わせようが、クラスタリングやネットワーク分散は当然
(以下コピペにつきry

**login:Penguin** · 2009/03/23(月) 22:37:22

まあおちつけカス共

**login:Penguin** · 2009/03/23(月) 23:03:56

Btrfsが今のzfs並みに安定するのに何年かかることやら。

**login:Penguin** · 2009/03/23(月) 23:15:36

930
結局922には反論できないのね

**login:Penguin** · 2009/03/23(月) 23:44:07

反論というか用途に合わせた構成ってのがほんとに必要なのかってのが疑問．
究極が一つあればいいじゃんというのがZFS（厨）の発想だと思う．
btrfsでも内蔵のRAIDは搭載するわけだし，
だんだんと統合する方向に流れてくんじゃないかな．

ZFSと同等の内蔵RAIDとスナップショットがあれば
LVMやMDの出番はないというか，あるだけパフォーマンス的にも
データの整合性的にも邪魔なだけ．

**login:Penguin** · 2009/03/23(月) 23:46:39

>>935
xfsをLVM上で動かすとバリアが無効なんて問題もあったりするしな

**login:Penguin** · 2009/03/24(火) 06:42:45

パフォーマンスはともかく、ZFSのおかげでコードの保守性も
操作も簡単になった。LinuxはSolarsiにまた引き離されてしまったな・・・

**login:Penguin** · 2009/03/24(火) 07:28:33

>Solarsi
って何だ。
何年もFのサーバーでSolarisを扱ってきたが、そんなOSがあったとはな。

ま、ZFS/btrfsがファイルシステムの未来の方向性であることは間違いないと思う。
あとハードウェアの性能がもう少し高くなればもっと利点を引き出せると思うぞ！なんとなく！

**login:Penguin** · 2009/03/24(火) 09:59:02

>>938
Solarsiを知らぬとはモグリだな。

**login:Penguin** · 2009/03/24(火) 10:11:15

いつまでもくだらん揚げ足取りをするな。キメぇんだよじじいw

**login:Penguin** · 2009/03/24(火) 11:38:03

>>936
2.6.29はdevice mapperがバリアをサポートしているみたいだぞ。

**login:Penguin** · 2009/03/24(火) 13:19:46

>>941
そりゃ2.6.29にしたら性能が落ちたと文句言う奴が出そうだな

**login:Penguin** · 2009/03/24(火) 13:21:25

ext4の件で文句が出るなら、出てもおかしくない。

**login:Penguin** · 2009/03/24(火) 17:50:10

>>941
rc8で試してみたが従来とおりバリアwriteに失敗する

**login:Penguin** · 2009/03/24(火) 18:44:28

PVが複数あると駄目なのかと思ってPV一つにしてみたが同じだな
コミット時のコメントを見ると
linearで単一デバイスをそのままマッピングした時だけ有効になるみたい
はっきり言って存在価値ゼロ

**login:Penguin** · 2009/03/24(火) 20:20:44

つ～わけで、btrfsがマージされた2.6.29が出たわけだが。

**login:Penguin** · 2009/03/24(火) 21:56:52

Andrew Mortonが2.6.30のmerge planでNILFSをマージすると宣言しましたね。今から強引にNAKする猛者は
現れそうにないから、ほぼ確定かな

**login:Penguin** · 2009/03/25(水) 00:25:47

久々にファイルシステムが熱いな

**login:Penguin** · 2009/03/25(水) 01:01:30

>>948
じじいと言われて発奮した人が頑張ってますので。

**login:Penguin** · 2009/03/25(水) 14:21:57

dfの結果とduの結果が全然食い違うんだけど、なんでかな
こんな感じで

# du -h -x -s /
5.3G /
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
15G 12G 2.2G 85% /
/dev/hda1 100M 13M 82M 13% /boot

duだと5Gでdfだと12G、こんだけ違うとさすがに戸惑っちゃうよ

**login:Penguin** · 2009/03/25(水) 16:00:22

>>950
つ hole
VMwareのディスクイメージとか置いてないか?

**login:Penguin** · 2009/03/25(水) 21:53:17

vmware server 2で仮想HDDを置くファイルシステムはxfsにしとくのがいいの？
体感だとext3との違いがわからんのだけど。

**950** · 2009/03/25(水) 22:00:37

>>951
ありがとう。
ホールじゃないことはわかりました。

**login:Penguin** · 2009/03/25(水) 22:02:40

せっかくカーネル2.6.29でbtrfsがメインライン入りしたのに人柱はいないのか？
他人の評価待ちのチキン野郎ばかりなのかい？

**login:Penguin** · 2009/03/25(水) 22:27:04

いる

**login:Penguin** · 2009/03/25(水) 22:50:16

>>955
レポートきぼんぬ

**955** · 2009/03/25(水) 23:38:12

SSDにてbtrfsを-o ssd,compress、64bit 2.6.29系で人柱。

なかなか速いし縮み具合もなかなか良い、と気をよくしていたら
15秒おき位にbtrfs cleaner辺りが1秒ほどCPUを100%食う
例の症状（というか仕様？）がやっぱり発動。
CPUが100%食われてる約1秒間は、作業によってはガクッと処理を
待たされる。
ちなみにというか当然ながらというか多数のbtrfsパーティションを
マウントしてるとえらいことになる。

というわけで現在は2.6.29のext4 journal無しに人柱移行。

**login:Penguin** · 2009/03/26(木) 19:08:16

GCっすか！

**login:Penguin** · 2009/03/26(木) 19:22:05

いやCGかもしれない

**login:Penguin** · 2009/03/27(金) 22:40:38

自動的に圧縮してくれるファイルシステムの名前ってなんて言うんでしたっけ。
記憶容量の少ないssdを導入したので、圧縮対応のファイルシステムを使おうと考えています。

それから、ファイルシステムの変更って大変ですか。
たとえばカーネルのパラメーターを触ったりしなきゃなりませんか。

何か、ヒントをください。
使っているディスﾄﾘは、セント５です。

**login:Penguin** · 2009/03/27(金) 22:41:54

自分で調べられないならヤメとけ

**login:Penguin** · 2009/03/28(土) 11:02:53

>>960
カーネルを読み、そして書き換える技術を身につけて出直せ

**login:Penguin** · 2009/03/29(日) 00:03:08

>>962
ファイルシステムを圧縮タイプのにするのは、
そんなにたいへんなのですかぁ。

簡単にインストール時なんかに選択可能なんだと思っていました。

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

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