12/09/22 17:29:34.03 13EzWjao
>>279
一応こんなテーブル持ってます。
URLﾘﾝｸ(opensource.apple.com)
281:login:Penguin
12/09/22 17:44:43.19 F/d1hvZ+
>>277
Linux側でどうにかファイル名ながくできないのか？
282:login:Penguin
12/09/22 17:48:50.42 13EzWjao
安易に変えるとLinux内でもバージョン間でファイルのポータビリティなくなるからな。
283:login:Penguin
12/09/22 17:48:58.82 LO7y59vv
>>281
しょばい話だけどNTFSをLinuxのext3でsamba共有使用とした時に
sambaのファイル名長に引っかかったと思う
sambaで解決してもext3でも引っかかるんじゃないかな
とりあえずサーバ側のディスクをiscsiでwindowsから使ってる
284:login:Penguin
12/09/22 17:55:44.77 AMpPKnTT
>>280
詳しく見てないけどU+1E9Eには未対応だろうね
285:login:Penguin
12/09/22 19:46:40.44 xakY400e
273です。
まだだったか。
286:login:Penguin
12/09/23 02:23:11.47 gJB1mzz5
>>272
その記事は半分嘘。normalizationで指定した正規化方法でファイルを記録してくれるわけじゃなくて、
単にFSにファイル名比較の要求がされたときに設定した正規化を行って比較するだけ。
要はformCと設定してNFDなドラえもんを書いてもNFDで記録されるが、NFCなドラえもんを書こうとしたときに同名ファイルが存在してると返してくれるって動作。
>>275の言うとおりnetatalkに任せておけばそうそう問題は起きないと思う。
ZFS+netatalkで個人的に試した範囲だとcasesensitivity=mixedを忘れた時の方が痛かった気が。
287:login:Penguin
12/09/24 19:24:33.87 BTwpUGaW
URLﾘﾝｸ(access.redhat.com)
＞ただし、 リンク数が 65,000 を越えると 1 にリセットされ増加しなくなります。
ってどういう動作なんだろう
288:login:Penguin
12/09/24 19:40:48.87 Ny4350Xt
リンクカウントって>2だから、1だと65000>を意味することにするんでしょ?
struct statのst_nlinkが16bitの互換性とサブディレクトリを65000以上作れることを、
回収できなくなることのデメリットよりも重視するということ。
289:login:Penguin
12/09/24 20:36:04.02 ntsLnrZa
回収できなくなるってどういうこと？
290:login:Penguin
12/09/24 20:46:40.60 Ny4350Xt
サブディレクトリをunlinkしても親ディレクトリのst_nlinkは1(実質∞の意味)のまま。
..の事知らないと何のことかわからないかも。
291:login:Penguin
12/09/24 20:53:25.94 Ny4350Xt
unlinkしても→rmdirしても
# 別スレでUnix V7のこと話していたからw
292:login:Penguin
12/09/24 21:01:33.25 ntsLnrZa
「回収できなくなる」の意味がわからなかった
「回収できなくなる」とはどういうこと？
293:login:Penguin
12/09/24 21:03:32.35 Ny4350Xt
ファイルシステムは、リファレンスカウントのガベージコレクションやってる。
294:login:Penguin
12/09/24 21:41:52.76 ntsLnrZa
もちろん nlink の話題で、デメリットとしての「回収できなくなる」を読めば、恐らくどこからも参照されないディレクトリが残ってしまい消すことができないと言っているんだと予想できる
しかし、コードを読んでも ext4 の rmdir は消したいディレクトリが空なら直接 nlink をゼロにするからnlinkの管理が適当でも正しく動作するし(1)、
実際に65000を越えるサブディレクトリを作ってみてnlinkが1になることを確認してから消しても、容量は元に戻り正しく消せたようだ(2)
そうなると「回収できなくなる」には、僕の理解とは別の意味があるんじゃないかと色々考えて、結果「どういうこと？」と聞くわけだ
にもかかわらず、質問に答えずに .. がどうとか、リファレンスカウントがどうとか別のことを言うのは、よくない
質問には正確に答えるべきだ
もちろん、僕の能力が低いせいで(1)の理解が間違いだったり、(2)が正しい実験ではなかったかもしれない
また、別のバージョンでは挙動が違う可能性は残っている
そもそも、「回収できなくなる」には別の意味があったのかもしれない
そういう色々な可能性が考えられるから、「回収できなくなる」とは何を意図しているのか、正確に知りたかった
295:login:Penguin
12/09/25 01:46:47.91 g8ftd0U7
これは質問が悪いだろ。
296:login:Penguin
12/09/25 14:51:59.61 hzHYhHyn
質問の仕方は悪いが抽象的なことして言ってない回答者も馬鹿
297:login:Penguin
12/09/25 14:59:20.83 MhTNZXB9
んじゃ答えてあげてよ。
298:login:Penguin
12/09/25 15:19:24.18 7mHujUYI
ディレクトリがハードリンクできる世界からタイムスリップしてきたとか。
299:login:Penguin
12/09/25 15:56:32.40 ie6CmTzc
ちがうだろ、パルスのファルシのルシがパージでコクーンだろ
300:login:Penguin
12/09/27 18:19:53.21 5QedY1DW
>>298
ln -d
301:login:Penguin
12/09/27 18:52:09.14 d5nghtd2
>>300
そういうことじゃねえだろ
302:login:Penguin
12/09/28 16:19:38.60 LQL56AZa
窓から放り投げろ
303:login:Penguin
12/10/03 20:02:48.65 OhisapLS
いやそもそも nlink ってのが何なのか……
304:login:Penguin
12/10/04 23:05:12.99 lFlv+tKp
URLﾘﾝｸ(lkml.org)
JFSにtrimが
305:login:Penguin
12/10/05 23:30:23.27 Vea7jgnN
jfs使いとしては喜ぶべきことだな。
reiser4が新しいカーネルにマージされるらしいね、こっそり開発続いてたのね。
306:login:Penguin
12/10/06 01:30:41.44 SkMTlz/z
まじかよ
いつのまにこんなページができてたんだ
URLﾘﾝｸ(reiser4.wiki.kernel.org)
307:login:Penguin
12/10/08 15:47:33.65 dFkmzqRr
草葉の陰でHansも喜ぶだろうな。
308:login:Penguin
12/10/08 18:31:03.39 5MeFU1N8
死 ん で ま せ ん
309:login:Penguin
12/10/08 18:40:10.87 S45asaXB
>>307
檻の中で
のまちがい
310:login:Penguin
12/10/08 19:27:40.22 GDmtR82r
>>307
若草の茂み に見えた。
311:login:Penguin
12/10/08 20:08:25.10 qjMSA1BQ
スレ
どうしてUbuntuは衰退したのか？
ｽﾚﾘﾝｸ(linux板:207-番)
でやりとりしていて疑問に思ったので教えていただけませんか。
GParted(Ubuntu12.04LTS 日本語Remix LiveCD)なんですが、
200GBのNTFSパーティションを右に100MB移動させるとき、
200GB全てを右に移動させているんじゃないかと思われるほど時間がかかりました。
パーティション先頭100MBにあったファイルを、新しく拡張される後端側の
空き領域に移動させて、それに合わせファイル管理情報を更新するだけで
良いと思うのですが、ダメなのでしょうか?
312:login:Penguin
12/10/09 01:40:18.33 7vUOMS0+
ダメでしょう
313:311
12/10/09 01:53:46.10 xUr78a+v
>>312
そうですか。
例えば300GBのパーティションを200GBに縮小するとき、後端100GBの場所にあった
ファイルは縮小される200GBの範囲内に移動されますよね。
それと同じように、パーティション変更後アクセスできなくなる場所にあるファイルは
変更後でもアクセスできる場所に自由に移動させることができるものだと思っていました。
314:login:Penguin
12/10/09 03:53:08.01 GYJBsMSY
その方法は新しい方の空き領域が足りなかったら破綻しますがな
まるっと移動するほうが確実
315:login:Penguin
12/10/09 07:15:52.92 ymL2JR8s
>>311
NTFSの実装は知らないけれど、
もしも、パーティション先頭からのオフセットで管理している要素があったら・・・
316:login:Penguin
12/10/09 08:08:37.44 nnyD2+Yn
普通は相対だろ何言ってんだ
317:login:Penguin
12/10/09 10:58:05.80 jHUE7sVE
そもそも、パーティションの先頭にあるのは管理領域だが。
318:login:Penguin
12/10/09 12:03:23.03 vXRMgl1q
MFTがパーティションの真ん中ぐらいに取られてて60%以上縮小できなかったのはいい思い出
319:login:Penguin
12/10/09 12:59:39.11 jHUE7sVE
MFTを拡大するときにMFTのフラグメンテーションが起きて、
それがパーティションの真ん中に来ることもあるね。
320:login:Penguin
12/10/09 14:04:37.36 CKsP2v7A
MFTは意図的に真ん中にくるようになってるでそ。
デフラグすると意味なくなるけど。
てかNTFSはスレ違いだろ。
321:login:Penguin
12/10/09 14:16:17.38 IbxiAjDm
その理屈だとext234,btrfs以外は板違い…
322:login:Penguin
12/10/09 14:20:01.72 nnyD2+Yn
Reiser4「！？」
XFS「！？」
JFS「！？」
XFS「？？」
323:login:Penguin
12/10/09 14:20:44.48 nnyD2+Yn
ZFSって書くつもりが間違えたし
324:login:Penguin
12/10/09 16:10:55.41 kmIlkpwM
実際には期待通り１００Mとちょっと動かしてただけでしたとかないですか
調べる気はないが
325:login:Penguin
12/10/09 17:23:11.63 8QjLalXf
NTFSはLinuxのデフォルトサポートFSだろ
326:login:Penguin
12/10/09 21:20:33.72 CqAL4Ml2
えっ
327:login:Penguin
12/10/10 10:13:54.27 5I1NvHWm
Android関係の話で、最近はUSBメモリをNTFSで使うのがデフォらしいと聞いたときはびっくりした。
328:login:Penguin
12/10/10 10:40:07.76 gsFvCtEe
FAT32じゃないんだ。
329:login:Penguin
12/10/10 10:45:07.24 i4SvHKD1
exFATとか言うの無かったっけ？
330:login:Penguin
12/10/10 10:58:55.37 2fT/Upxm
あったよ。
331:login:Penguin
12/10/10 11:02:45.64 GgqJQq9Q
ntfsでも大抵の環境は大丈夫なんだろうけど
俺は未だにfat32にしてるな。
ntfsはMacOSやLinuxだといちいちntfs-3gでマウント仕直さないといけないし
332:login:Penguin
12/10/10 11:48:24.24 gsFvCtEe
>>331
俺も、USBメモリとかSD(HC)カードとかだと基本的にFAT32だな。
外付けHDDだとext3/4やNTFSにしたりしてることもあるけど。
PC以外のデバイスで読む可能性が大きい場合はFAT32が鉄板かな、と。
333:login:Penguin
12/10/10 12:04:18.33 l0NrRCCs
>>330
exFATがUSBメモリ用途のFAT32の後継になるもんだとばかり思ってた
MSはそのつもりで作ったんでしょ？
>>331-332
最新情報を把握してないんだけど・・・・
ntfs-3gって今は十分な信頼性あるのかな？
LinuxとWindowsで読めて1ファイル4GB以上OKなファイルシステムでずっと悩んでる
Ext2FsdのExt4サポートって、実用上問題ないレベルに達したのだろうか・・・
もう1年以上アップデートしてないみたいだし・・・
とりあえず今はext3を共用用途で使ってるんだけど、できればNTFSかext4に移行したい
334:login:Penguin
12/10/10 12:25:43.79 CD0ab8oM
UDFの出番
335:login:Penguin
12/10/10 12:28:09.60 gsFvCtEe
>>333
十分な信頼性があるかっていうと、ちょっと分からないけど。
個人的には、内蔵HDDのWindowsとの共用領域はNTFSにしちゃってるな。
マウントしている時にカーネルが刺さったりすると、再起動してもntfs-3gがエラーを吐いてマウントできないことがある。
そうなるとlinux側だけでどうにもならなくなって、Windows側でchkdskが必要になることがある。
本当に稀だけど。
336:311
12/10/10 17:29:04.85 yPSAXVKc
>>311です。
皆さんレスありがとうございます。
>>324
8.0GBのNTFSパーティションで試したのですが、
・縮める時は、その分だけのファイルを移動させているようですぐに終わりました
・右、左に移動させるときは、全てのファイル(セクタ(?))が移動されるようです
色々調べたり皆さんの書き込みから、
NTFSの仕様が完全に公開されていなくて、GPartedはMFTのパーティション内オフセット位置を
変更(MFTを移動)する操作が出来ない。だから、確実な「全体移動」をする。
と考えています。
337:login:Penguin
12/10/10 20:52:27.75 v385fBlC
遅ればせながらZFS Linux Native RC11が出てましたね。
特に問題なく使えています。
いつになったらRCが取れるんだろ。
338:login:Penguin
12/10/10 23:27:04.84 +ZrJmI38
win共用のusbメモリとか随分前からntfs一択だな
339:login:Penguin
12/10/11 00:01:58.07 tHQ9bcc5
でも、USBメモリとかは、暗号化がついたFSじゃないと使えなくない？
340:login:Penguin
12/10/11 00:03:55.44 WS6FvsE5
大切なデータはもちろん暗号化したFS領域にいれてるよ。
全部暗号化しちゃうとデータの受け渡しにすら使えないし。
341:login:Penguin
12/10/11 09:33:33.91 V5vBYLQ+
暗号化すると漢字やカタカナのフォルダ名は文字化け起こしてしまうけどな。
342:login:Penguin
12/10/11 09:49:29.10 /wU9AuKr
どこの糞ソフトだよ
343:login:Penguin
12/10/11 16:25:44.56 GYQK0rbP
>>336
NTFSの先頭はMFTって決まってるんだって。
何がどこにあるかは全部MFTに入ってるのに、
MFTの場所が決まってなかったらファイルシステム読めないべさ。
344:login:Penguin
12/10/11 20:34:32.36 Wk88iD1l
単純な全体移動だけじゃなくてBPBの書き換えもやってるという理解だったが最近のは違うの？この手のツール。
345:login:Penguin
12/10/11 20:40:39.68 Wk88iD1l
あとこの手の全体移動するツールって移動中に電源落ちても続きから再開できるような対策とか打ってるもんなん？
346:デムパゆんゆんネトウヨ特攻兵＠１０月 読書の秋 【関電 64.6 %】
12/10/11 22:40:43.93 QNMVCMvf
続きはCMの後
347:login:Penguin
12/10/12 10:25:11.66 GbJnfzSW
>>345
中断しても整合性をキープするのが理想だと思う。
転送前後が重なってるなら、一時的に双方を含むパーティションに拡大して、
デフラグ類似の処理をしながら転送前だけの範囲から追い出して、
その後に転送後の範囲に縮小。
てな面倒な処理をしてくれるといいんだけれど。
348:login:Penguin
12/10/12 10:26:46.27 HHTpRhDv
理想語ってる暇あったら自分で実装すべし
349:login:Penguin
12/10/17 14:17:43.56 vrMwbUL5
他スレでこんなこと言ってる人がいたが、どうよ？？
------------------------------------------------------------------------
NTFSのセキュリティ設定はデフォルトの状態でよくできている
※デフォルトのUNIXのファイルパーミッションは最低といってもいい
というかそもそも共有という認識がない
それでも問題点にならないには非常に小規模の共有にしか使わないから
UNIXでも同等のことができるという意見もあるが「実運用したことのない奴の戯言」である
NTFSのエラー訂正機能はext3より若干上(ext2よりは良くなった)
（割と馬鹿にされるがCHKDSKは神ツールである)
350:login:Penguin
12/10/17 14:37:51.35 jvY0yRQX
>>349
どうよって言われてもな・・・
Windowsユーザーから見れば、まぁそういう言われ方するよねぇ。
ぐらいかと。
Windowsメインの共有なら明らかにLinux+sambaのが分が悪い（当然だけど）
acl周りもしかり。
サーバーとしてWindows用意出来るなら、わざわざLinux+samba使う必要無いしな。
色々反論したいところも有るだろうが、
この書き方してる奴に反論したところで、
徒労に終わるだけじゃね。
ってのが、感想。
351:login:Penguin
12/10/17 14:42:42.34 DCqsgCSI
まぁ、適材適所。
352:login:Penguin
12/10/17 14:47:01.24 YMHv2yu3
>>350
思考が狭すぎ世間をしらなすぎ、お前の言うそれはインストールされた
台数でいえば極狭い世界の知識だ。
353:login:Penguin
12/10/17 14:47:45.63 DCqsgCSI
>>352
では経験豊富なあなたの意見をどうぞ。
354:login:Penguin
12/10/17 14:52:30.65 9QEPxsDD
やめろや。比較は荒れるだけ。
いちいち釣りに付き合うな。
355:login:Penguin
12/10/17 15:11:25.66 01TKgxYE
デフォルトがどうとかファイルシステムの仕事とは違くね
356:login:Penguin
12/10/17 15:16:30.84 PvZAHEIs
> NTFSのエラー訂正機能
そんなのあるの?
と思って検索したら最近はそういう機能がついた?
URLﾘﾝｸ(cloud.watch.impress.co.jp)
357:login:Penguin
12/10/17 15:50:25.17 jvY0yRQX
>>352
そうカッカするなよ。
Linuxとか分からないWinユーザーなんてそんなもんだって。
言いたい事は分かるが、最後にちゃんと感想書いただろ？
関わるだけ無駄だと。
だから落ち着けって。
358:login:Penguin
12/10/17 19:31:09.12 SWsIj1dy
そういう話ならスレ違いでござるな
359:login:Penguin
12/10/17 19:47:05.38 SC1964Pi
NTFSは不良クラスタが発生すると自壊して被害が拡大するから嫌い
FATの頃は不良クラスタ発生箇所のファイルの問題だけに極限してたのになぁ
360:login:Penguin
12/10/17 20:48:59.24 RbpW1EIX
bad block handlingの無いXFSにも同じこと言えんの
361:login:Penguin
12/10/18 11:55:37.22 QvtQjgLZ
>>359
まだWindows2000が現役だった頃その罠にハマったわw
結局その時の常用はFATにした。
362:login:Penguin
12/10/18 16:35:38.24 LrtYvlyT
早くこんな世界が来るといいな
メモリ技術の革新がコンピュータアーキテクチャの変革も導く
URLﾘﾝｸ(pc.watch.impress.co.jp)
363:login:Penguin
12/10/18 18:02:34.17 nEi/VRh3
いよいよWinFSの時代か！
364:login:Penguin
12/10/18 21:42:23.50 Uwcr8ZaT
Wii のバーチャルコンソールとかのゲーム機エミュレータで遊ぶと、
どこでもセーブがありがたいけれど、
不揮発メモリもそんな感じかな？
365:login:Penguin
12/10/18 23:04:38.08 CZbR+4vN
なんとなくサイバーパンクっぽいけどオブジェクトのリンクをたどるのもi-nodeのリンクをたどるのもあんま変わらん気もする
366:login:Penguin
12/10/18 23:27:58.96 Svf3uX/8
HDDがPCからなくなる事はあってもファイルシステムは残る、
ファイルをメモリに再展開しないで直接参照するようになる、
それは現状でも可能。
PRAMが一番単純だ寿命はMRAM、RAMはMRAMになりFLASHはPRAMになる、
速度が稼げればMMは1GBで十分、MMとPRAM間の転送を100GB/sに高める。
スパコンやクラウドは既にメモリ＋演算機構の分散システムになっていて、
大規模な処理ではICｰNWの速度がその性能を規定している。
367:login:Penguin
12/10/22 16:00:09.50 o36esTpA
>>349
Windowsのファイル共有がクライアントも含めてセキュアになったのなんてここ10年の話じゃないか。
10年前はサーバですら追加パッケージ入れないとITSECの規準も満たさなかったし。
今もProfessionalじゃないと話にならないだろ？
368:login:Penguin
12/10/22 18:41:11.05 N8Jtvfqg
XFSとFTPに出会えた事を誇りに思う
こんな事が言える男が世界にどれだけいるだろう
心から感謝している
369:login:Penguin
12/10/23 02:09:12.40 WU9pwdoJ
>>366
その手の話は楽しそうだけど、スレ違いだから遠慮しておく
370:login:Penguin
12/10/23 06:54:16.77 9JHFz3mT
遠慮せず、スレ移動して続けたら?
371:login:Penguin
12/10/23 12:26:22.73 0oB+osl5
gnomeのごみ箱がntfsに対応していない
372:login:Penguin
12/10/23 18:37:45.79 ZFhcO2Ju
パーティションに書き込み権限が無いだけ
373:login:Penguin
12/10/25 08:43:13.91 zqYpInVT
AppleのFusion Drive
SSDとHDDのいいとこ取りのディスクシステム。
Linuxのファイルシステムでまねっこするには、
FlashCacheが一番近いかな。
374:login:Penguin
12/10/25 16:21:46.50 wiAOfp6Y
Appleの売り文句を真に受けるとバカを見る
375:login:Penguin
12/10/25 16:39:14.43 dcwDITH+
Hot Dataという仕組をVFS上に考案されていてまずbtrfsへの実装が進められている。
376:login:Penguin
12/10/25 16:39:49.21 dcwDITH+
>>375
> Hot Dataという仕組をVFS上に考案されていてまずbtrfsへの実装が進められている。
Hot Data Tracking
377:login:Penguin
12/10/25 23:34:28.46 UqYCZsNh
[Phoronix] EXT4 Data Corruption Bug Hits Stable Linux Kernels
URLﾘﾝｸ(www.phoronix.com)
カーネル3.4以降のExt4でファイル破損の不具合ですか。
それとも3.6.2の話かな。
私は2.6.32だけど心配だからExt3で再インストールしようかな…。
378:login:Penguin
12/10/26 02:57:48.55 Gx6HHt8O
3.6.2で入ってその後3.4にもバックポートで混入
379:login:Penguin
12/10/26 08:39:13.13 gJ8NKbwz
バグの発動条件は短い期間にmount/unmountを繰り返すことみたいだから、
当たることもそうはなさそう。
2.6系だとむしろext4のコードが古すぎて微妙とかないのな。
380:login:Penguin
12/10/26 08:40:26.38 O4FrXTWG
それってautofsとか使ってるとアタる可能性があるってこと？
381:login:Penguin
12/10/26 10:13:36.36 b7aJ0gK4
>>376
なるほど、btrfsの今後の実装を刮目して待て！！
という話ですね。
382:login:Penguin
12/10/26 12:31:52.08 Fqb7Vkhu
抜く前にsyncsyncsyncすれば回避できるかな？
383:login:Penguin
12/10/26 15:42:47.69 pT4dWmUW
>>377
>>379
URLﾘﾝｸ(plus.google.com)
によると
今のところ調査中みたいだけど、かなり限られた状況じゃないと破損は起きないみたい。
umountせずに電源を切る(umount -l後にbusyが解消される前に切るとか)
次回mount時にnobarrierオプション付きでマウント
この二つを満たした時に破損の可能性が出てくるらしい。
とりあえずnobarrierをつけてない人は、まぁ大丈夫でしょ
384:login:Penguin
12/10/27 00:52:26.66 2cXd+0y5
アンマウント完了前に電源が切られることがある…のか。
そういえば以前から気になっていたけど、Linux終了するとき
外付けのUSB-HDDが「カキューン」とか鳴って
いきなり電源切断されたようになる。
(サスペンド中もUSB-HDDのモーターが回っている)
Windowsなら、HDDのモーターが止まってから静かに電源断されるのだけど。。
(サスペンド中はUSB-HDDのモーターが止まっている)
今回の修正でついでにそこまでやってくれないかな…。
385:login:Penguin
12/10/27 02:15:46.98 ZNGg/pVZ
>>383
バグかぉ！？
Xが固まって強制リセット後破損
nobarrierつけてるから破損したんだな仕方ない自業自得か
と思って納得してたんだが…？なんか間違ってる？
386:login:Penguin
12/10/27 17:34:09.20 kLEmFi68
今時のファイルシステムは、不意のシャットダウンでも、破損するんじゃなくて、
新しい書き込みが捨てられるだけであることが期待されてる。
387:login:Penguin
12/10/27 17:44:06.09 AGi5NFZt
それをファイル破損と言うんじゃなくって？
388:login:Penguin
12/10/27 17:48:52.80 kLEmFi68
元記事の英文が読めないんだねえ。
389:login:Penguin
12/10/27 23:19:31.81 GpxaDLzd
>>387
？
390:login:Penguin
12/10/27 23:25:13.01 +7274N+z
書き込みされないのに破損するわけない
391:login:Penguin
12/10/28 00:43:00.91 EGMMc3VL
アプリが書き込んだと思ってるのに、書かれていなかったらファイル破損なんでは？
392:login:Penguin
12/10/28 00:54:10.66 4sjbxmQV
どういうバグなのか理解してから書き込めよ。
「ファイル破損」とかアホかと。
393:login:Penguin
12/10/28 03:02:33.87 qwr6u3Ap
データの損失だな。
フラッシュされてないんだからしょうがない。
394:login:Penguin
12/10/28 03:18:53.76 4iK8nRu6
面倒だからいつも電源ボタン長押しでぶち切ってたから心配だお
まあ破損して困るようなデータじゃないからどうでもいいけど
395:login:Penguin
12/10/28 05:23:47.58 CJGiM68r
ハードディスクの損傷の修復機能はあるだろ？
396:login:Penguin
12/10/28 07:45:58.13 YHACL08l
ハンスごめん
EXT4に浮気した俺が間違ってたよ
397:login:Penguin
12/10/28 11:52:40.99 4sjbxmQV
>>393
はあ？
398:login:Penguin
12/10/29 19:41:09.31 eLEF2BXb
よし、仕事終わったしバックアップ取っておくか
$sudo zfs snspshot rpool/export/home@today
楽チン~
399:login:Penguin
12/10/29 21:08:47.00 3OuSbDia
LinuxのくせにZFSとかずるい
400:login:Penguin
12/10/29 21:28:37.16 1Bghux58
思うにXFSとは、もともとあるものとも言えぬし、ないものとも言えない。
それは地上の道のようなものである。
もともと地上には道はない。
歩く人が多くなれば、それが道になるのだ
401:login:Penguin
12/10/29 23:43:50.62 6l5+Yl0S
スナップショットはバックアップじゃねぇしｗ
402:login:Penguin
12/11/01 22:38:04.00 gzHmXVmP
バックアップの意味を広く捉えるか狭く捉えるか
オペチョンで消したファイルを復活できるのだって広い意味ではバックアップに違いない
物理障害に耐えられないだけで
403:login:Penguin
12/11/01 22:55:53.70 InrMq2kC
いやいや、そこは区別しようよ。
バックアップ、スナップショットで意味は明確なんだから。
404:login:Penguin
12/11/01 22:56:24.00 XjtB3TGE
backup の意味は予備とか代役とか非常用とか
405:login:Penguin
12/11/01 23:13:38.79 zilQmaYL
ファイルシステム的には
$ cp hoge.txt hoge.backup
とほぼ同等のことをCOWでやってる訳だしバックアップって言ってもいいんじゃないの
バックアップが同じHDDあっちゃいけない決まりがある訳じゃないし
406:login:Penguin
12/11/01 23:18:20.03 x/7V4pPf
複製しないし
407:login:Penguin
12/11/01 23:23:33.64 InrMq2kC
簡単なんだから使い分けましょう。
ベル研のWORMみたいに、光学ディスクにバックアップしながら、
いつでもアクセス可能なスナップショットを作成するのなら、
区別しがたいわけだけど。
408:login:Penguin
12/11/01 23:31:05.46 ssBg5K4m
呼び方は置いとくとしても、
スナップショットじゃハードウェア障害に無力だよね。
409:login:Penguin
12/11/02 09:27:58.19 rb1niAqP
オリジナルが必須な時点でバックアップじゃ無いじゃん
410:login:Penguin
12/11/02 11:33:42.33 uIcmYoX5
別ディスクへのバックアップだって遠隔地に取ってなけりゃ災害には耐えられない
何に耐えられるかを以ってバックアップかどうかを定めるのはあまり意味が内と思う
コピーやスナップショットやリモートミラーは実現するための技法に過ぎなくて、
非常時に代替として使えるものは何だって広義のバックアップだろうよ
411:login:Penguin
12/11/02 11:46:35.99 jcF3AZ8S
pgr
412:login:Penguin
12/11/02 11:52:21.97 doWgnh0V
>>410
極端な例を挙げても、バカがいっそう引き立つだけだぞ。
413:login:Penguin
12/11/02 11:54:07.86 rb1niAqP
遠隔地でなきゃバックアップも死ぬよっていうのは別次元の話だな
バックアップの本質的な意義は、明らかに一部または全部が欠損したオリジナルの復元だから
スナップショットも条件限定でのバックアップと言えなくもない
ただ、システムの運用管理を行う上で「バックアップとスナップショットは区別されるべき」っていう話だと思うぞ
414:login:Penguin
12/11/02 12:06:26.07 uIcmYoX5
専門バカ的に、バックアップって言葉の意味を限定しすぎてるだけ
その世界では(狭義には)オリジナルと別の実体を要求されることくらいはわかってる
バックアップという目的に対して適切な手段が場合によってスナップショットだったりディスク内コピーだったりディスク外コピーだったりリモートコピーだったりするだけ
415:login:Penguin
12/11/02 12:15:19.34 rb1niAqP
名称や定義は重要だぞ
まあお前さんは今まで痛い目を見たことがないラッキーガイなんだろうよ
416:login:Penguin
12/11/02 12:54:39.09 uIcmYoX5
名称や定義に無頓着なのはそっち
417:login:Penguin
12/11/02 12:58:42.56 doWgnh0V
>>416
いい加減にしろ、ぼけ
418:login:Penguin
12/11/02 13:29:52.86 GQBvMhUy
的外れな『極論』を持ち出した時点でID:uIcmYoX5の負け
419:login:Penguin
12/11/02 13:39:28.50 ZWB+hg7e
ゆワイターはあっち
420:login:Penguin
12/11/02 14:27:16.67 M+3/Tt7Z
同じディスク内のコピーはバックアップではない
その認識が浸透していたならファーストサーバの事件は防げたかもしれない
421:login:Penguin
12/11/02 16:08:02.73 O/ZR7tTp
>>420
認識が足りないのはお前だろ…
ファーストサーバでは別ディスクにまるごとコピー（二重化）も取ってあったんだよ。
ところが馬鹿な社員がそっちにもバグ入りOSアップデートしたせいで
コピー側も見事にぶっ壊した。
ホット側とコールド側双方一緒に環境更新とか無能としか言いようが無い。
422:login:Penguin
12/11/02 16:30:13.28 GQBvMhUy
>>421
認識が足りないのはお前だろ…
ファーストサーバは待機系をバックアップと称していたけど、
待機系はあくまで本番系に対する（機能としての）バックアップであって、
データとしての『バックアップ』ではない。
そこがごっちゃになってるから話がおかしくなるんだよ。
データとしてのバックアップじゃないんだから、本番系・待機系ともにパッチ当てるのは当たり前。
じゃなきゃいざって時に待機系が使いものにならず、待機系の意味がない。
423:login:Penguin
12/11/02 16:45:48.44 jcF3AZ8S
バカな運用者というのはbyzantine failuresの典型例ですね。
424:login:Penguin
12/11/02 17:41:18.21 RxNdjvVD
この流れ、同じようにバックアップやRAIDについて得意げに解説してくれていたシステム構築発注先のSEが
数日後ノートPCが壊れたとかで、
これまでのメールや資料を再送してくれと泣き疲れた思い出が呼び覚まされた。
425:login:Penguin
12/11/02 17:45:48.11 cPFlJ0Jm
>>410
ポケコンに打ち込んだベーシックのプログラムを、
紙に写経してバックアップしたのを思い出すわｗ
426:login:Penguin
12/11/02 18:41:50.82 6OZ7uj4a
紙にメモするのも立派なバックアップの手段
427:login:Penguin
12/11/02 19:08:12.68 aQt6ihWu
紙にバックアップは最終手段だね。
少なくともPCで取り扱うよりも並べ替えも移動も検索も難しくなるし、
機密情報だったら暗号化もできない。
428:login:Penguin
12/11/02 19:15:38.10 cPFlJ0Jm
しかもだいたい書き間違うしなｗ
まあそこは、復元するとき柔軟に読み込むから相殺されるけど。
429:login:Penguin
12/11/02 19:21:33.39 GPiMhI3k
ふっかつのじゅもんか
430:login:Penguin
12/11/02 22:04:39.91 QbgCEqw1
最近物忘れが多いからメモするようにしたんだが
自分でも読めないくらい字が下手で困る
431:login:Penguin
12/11/03 00:44:45.77 GUd3rUXm
Ext4のバグがまだあるという…
[Phoronix] There Might Be Another EXT4 Corruption Bug
URLﾘﾝｸ(www.phoronix.com)
要は64bitのUbuntuにおいて、12.04で作ったExt4に12.10を入れて
12.10のfsckをすると、ファイルシステムが100%クラッシュする
ということかな。
432:login:Penguin
12/11/03 01:53:20.00 OhvRX3Pe
暗号化とエラー訂正コードを付けてからメモすれば
433:login:Penguin
12/11/03 02:05:55.89 Ez1EqqwX
>>431
ext4がまだ枯れていないという事だろう
安定するためにはもっと人柱が必要なんだ
434:login:Penguin
12/11/03 02:38:00.48 GUd3rUXm
カーネルが
・Ubuntu 12.04 ～ ver 3.2
・Ubuntu 12.10 ～ ver 3.5
なので、似たような状況でも問題が発生するかも知れませんね。
435:login:Penguin
12/11/03 08:50:10.05 x4u+yq7+
まあでも新しいファイルシステムなんてそんなもんだよな。
ZFSも結構問題起きるみたいだし。
436:login:Penguin
12/11/03 09:20:19.76 F3mzMXS2
ext4が枯れていないのにext4でfixされたバグがext3にバックポートされていないものがあるという
437:login:Penguin
12/11/03 09:22:02.50 GUd3rUXm
DebianがExt4を採用しているから大丈夫だと思ったんですが。。
でも今回のはカーネル3.5、先日のは3.4～3.6。
Debian(wheezy)は3.2だから大丈夫かな。
438:login:Penguin
12/11/04 08:33:32.52 DxPDnXqB
XFSはいいものだよ
多分最高のものだ
いいものは決して滅びない
439:login:Penguin
12/11/04 11:55:42.62 DRJDnh5/
btrfsに駆逐されろ
440:login:Penguin
12/11/06 03:57:02.55 pISgWimS
>>438
いいものではなく、商業的に成功したものだけが生き残る
441:login:Penguin
12/11/07 11:08:25.38 rn8yLjcX
Suse Enterprise Server Lnux 11を使ったサーバ構築の案件があって、
試しに仮想PCにインストールしてるんだが、ファイルシステムの
選択にbtrfsが出て来てビックリした。 選ぶと、/パーティションには
使えないらしくインストーラで先に進めないが、データ
パーティションには使えるみたい。
442:login:Penguin
12/11/07 16:34:18.60 WkY+xawT
grub2ではgrub.cfgでinsmod nilfs2を指定できるようになったので、
nilfs2を普通にrootで使えるようになった。
それにしてもnilfs2のファイル削除の遅さは気になるな。
443:login:Penguin
12/11/07 16:50:54.73 s8f4SsG0
全く関係無いんだけど誰も話す相手がいないから書かせてくれ
随分前から海面上昇が問題になってるけどさ
あれって世界中が貿易が盛んになって
でっかいコンテナ船やらタンカーをたくさん浮かべたからだと思う
北極の氷が溶けたのが原因って言われてるけど
氷って元々ほとんど水の中だし溶けたら逆に体積減るからあんま関係ないと思うんだよね
どうだろ？
ちなみに俺はXFSが好き
444:login:Penguin
12/11/07 16:53:26.38 4OoAyn3a
長いファイル名サポートはよお願い
445:login:Penguin
12/11/07 16:55:02.28 FcTcq6ln
>>443
ひとり言はこっちで。
URLﾘﾝｸ(kohada.2ch.net)
446:login:Penguin
12/11/07 20:31:58.27 JJe03jty
海面上昇とXFSに何の関係が？
447:login:Penguin
12/11/07 22:24:16.18 mdV+jyok
データセンターは山の上に作れってことさ
448:login:Penguin
12/11/07 22:47:44.71 lMZK0FqX
データセンター立てるなら滋賀がいいですよ～
環境いいし交通の便いいし海抜80m以上あるから海面上昇とは無縁だし
449:login:Penguin
12/11/08 02:16:29.58 7q9PSQRu
寒くないと空冷できないべ
雪でも降れば貯めておいて使えるが
450:login:Penguin
12/11/08 02:33:19.97 /O1n10+6
滋賀は結構雪降るよ
451:login:Penguin
12/11/08 03:51:16.16 +t0fE3Pf
滋賀って例の大津市ある所じゃないか……。
452:login:Penguin
12/11/08 08:06:26.32 ulF68DIF
何のスレだよ。
453:login:Penguin
12/11/08 09:34:55.84 uMkvhnVA
データをイジメ殺すからやめてください！
454:login:Penguin
12/11/08 11:45:53.05 HTy/v2GZ
いじめの名所滋賀県
455:クラウドはドリームソルジャー？
12/11/08 12:18:43.74 +L/AjMM3
雲散霧消に定評のあるファーストサーバー。
多くのデータが消えていった。
456:login:Penguin
12/11/08 13:43:40.71 FNcrRuT7
常時snapshotのNILFSなら無事だったのにね
457:login:Penguin
12/11/09 00:14:21.82 qlO8XAcr
32bitカーネルと64bitカーネルでファイルシステムの違いが生じるってこと
ありますか？
458:login:Penguin
12/11/09 11:12:38.73 lm7rqEO+
開発者も64ビットと32ビットの両方の環境で動作するのが面倒らしく、
64ビットなら動くけど、32ビットでは動かなかったという事例は
ありそう。ファイルシステムでは無いが、別のシステムで経験があるよ。
開発者にメールしたら「え、32ビットまだ使ってるの？」って。
真面目なヤツで、次の日には改修済みの32ビット版のオプジェクトを
作ってくれたっけ。
459:login:Penguin
12/11/09 12:03:21.07 S4+d2JBp
ま、Linuxであえて32bit使っているのはUbuntuの馬鹿どもぐらい、
というイメージだな。
460:login:Penguin
12/11/09 12:26:52.89 tly6/47p
Droid君がアップを始めたようだ
461:login:Penguin
12/11/09 14:46:00.73 EhvrUbww
>>459
お前も馬鹿だろ。
まだまだ非64bit環境でLinux使ってるの多いんだよ。
462:login:Penguin
12/11/09 14:53:12.28 Gjeu7Hay
>>459
おまえのイメージはPCの話だろ
linuxは組み込み用との方が圧倒的に多いだろ
463:login:Penguin
12/11/09 15:37:42.41 TSMauyzz
>>462
でも組込みも64bit化してかないとヤバイ
2038年問題がヤバイ
464:login:Penguin
12/11/09 15:43:06.11 nMUC+MIA
アホかと。
カーネルの64bit化と2038年問題は関係ない。
time_tはカーネルの64bit化とは関係なく、既に64bit化されてる。
古いファイルシステムの内部データに32bit time_tが残っているのは大問題だが、
カーネルを64bit化すれば直るわけではない。
465:login:Penguin
12/11/09 16:01:17.49 NCnS2ylI
もったいないのが
64bit対応CPUで32bit使うこと
Ubuntuは未だに32bitがrecommendedだし
あと広く普及しているcore2duoは64bit対応だけど32bit全盛期に発売されたから未だ多く32bitCPUとして使われている
64bitにしたら有効メモリーはもちろん処理が速くなる
メモリー4GBも使わないからいいやとかPAEでいいやとか思わずCPUが対応してるならどんどん64bitにすべき
466:login:Penguin
12/11/09 17:38:26.30 J6obOOP6
適材適所がわからないバカはどうしようもないな
467:login:Penguin
12/11/09 18:19:26.77 tb9hKVQD
拙者32bitのUbuntuを使っている馬鹿でござる
468:login:Penguin
12/11/09 18:41:17.89 PEnheJzq
左様でございますか
469:login:Penguin
12/11/09 18:51:15.82 TsbbGiwx
ユーザーランド64ビットでもまあ構わないんだけどポインタは4バイトでじゅうぶん。どうコンパイルしたらいい？
470:login:Penguin
12/11/09 18:56:19.18 nMUC+MIA
自分でコンパイルしたコンパイラとライブラリを使ってください。
システムコールはポインタ渡しの部分が32bit版と64bit版と二種類用意されているので、
適切な方を呼び出すようにしてください。
後はELやld.soF内に閉じた話なので好きにやってください。
471:login:Penguin
12/11/09 18:57:21.62 J6obOOP6
使用目的に合わせて機器・使い方を選ぶのが適材適所であって
64bit対応ハードウェアなら何が何でも64bitで使うべきとほざくのがバカ
472:login:Penguin
12/11/09 19:08:08.64 NCnS2ylI
>>471
だってせっかくのCPUの性能をフルに発揮したいじゃん
「処理速度が向上する」を不必要と思う人はいないじゃん
473:login:Penguin
12/11/09 19:15:50.18 pbnT+2De
リスト構造をダンプして上位4バイトほとんど同じのみたらメモリーもったいないんだの。
IL64もしくはL64モデルでいい。
474:login:Penguin
12/11/09 19:17:07.84 pbl6itVC
>>472
キャッシュにおさらまらなくなると遅くなるよ。
475:login:Penguin
12/11/09 19:51:15.22 H1ZvvXvX
64bitにしたって、普通の用途では速度向上はほぼ実感できないだろ。
むしろメモリフットプリントが単純に増えるから、メモリが4GB以下なら64bitにするメリットがほとんどない。
476:login:Penguin
12/11/09 20:00:59.27 9NSaHAI2
x32ABIでいいじゃん
つか、FS関係無いだろ
477:login:Penguin
12/11/09 20:11:59.07 7LQKEDvt
x86にたいするx64なら64bitという点ではなくISAの拡張による利点がある
汎用レジスタが増えたり命令相対アドレッシングが可能になったり
478:login:Penguin
12/11/09 20:14:46.74 3ru+Kify
AMD64はレジスタ周りの設計改善で、64bitで使った方が速いらしい。
479:login:Penguin
12/11/09 20:39:17.08 HjNXfa0O
精度がfloatでじゅうぶんならdoubleより速いのにdoubleの固定観念を捨てられないおじさんみたい。
480:login:Penguin
12/11/09 22:00:33.07 VDgsiS8o
ubuntu64bitだとfluxbox環境でmltermのアイコンがなぜか化けまくる
481:login:Penguin
12/11/09 22:39:07.44 nMUC+MIA
/usr/share/pixmaps/mlterm*を全部表示してみてください。
というかスレ違い。
482:login:Penguin
12/11/10 03:08:21.46 skqN2pV+
>>479
x86のFPUは倍精度で動いとるからdoubleの方が余計な変換処理入らない分速い
てファイルシステムとどう関係あるんだ？
483:login:Penguin
12/11/10 03:42:22.35 BtRf1foD
>>482
別にかわらんのじゃないのか。
変換処理なら内部80bitだからdoubleでも入るぞ。
484:login:Penguin
12/11/10 06:07:04.85 CGoNRL+B
SSE
485:login:Penguin
12/11/10 08:08:42.58 yA/REe8u
>>464
sys_timeシステムコールを見るとtime_t返してるし、libcと同じくカーネル内でもlongで定義されてませんか？
486:login:Penguin
12/11/10 08:51:07.94 xknH4hBW
>>481
32bitと64bitで差がなかったyo
487:login:Penguin
12/11/10 09:33:08.87 J4Ln9o96
80bitって今日日x87コードなんか誰も書かないと思うけど
現状x87はコードは推奨されてないしコンパイラーもんなコード吐かない
488:login:Penguin
12/11/10 12:32:14.43 VbwvG4Uy
>>482
コントロールレジスタを_FPU_DOUBLEに設定していようが変換入るんだがね
489:login:Penguin
12/11/10 16:14:21.76 DAGxbFTw
ext4 の defrag まだかな。
490:login:Penguin
12/11/10 16:47:14.79 PrjxxuV6
e4defragとかfake_defragとか？
491:login:Penguin
12/11/10 17:08:37.17 Swni5aMO
linuxのデフラグはコピーして戻すのが王道だろw
492:login:Penguin
12/11/11 01:22:09.46 troQki0D
>>489
なんでデフラグしたいの?
493:login:Penguin
12/11/11 06:58:19.57 2Eng4Y+V
昔「デフラグする奴は貧乏人」ってスレがあったな
494:login:Penguin
12/11/11 10:40:48.36 osAwJNEG
デフラグする奴はアホ
初期化する奴のほうが情強
495:login:Penguin
12/11/11 10:46:04.14 bP6rS7i3
本当の情強はLinuxなど使わない
496:login:Penguin
12/11/11 10:48:05.27 QIAgZ7z2
freeBSDでZFSを使う
497:login:Penguin
12/11/11 11:07:33.39 3kaPvPl7
SolarisやHaikuもいいな
498:login:Penguin
12/11/11 16:23:07.56 0JBWKQCc
そもそもLinuxが沢山のファイルシステムをサポートしてるのはなぜ？
初期にメインファイルシステムをどれにするかで、迷走したとか？
499:login:Penguin
12/11/11 17:08:34.59 qt5OlzxZ
>>498
最初はExt系だけで、Linux気質の「来る者拒まず、去る者追わず」でどんどん増えた様な。。。
500:login:Penguin
12/11/11 17:30:17.28 e/1Iatys
ext2の実装がひどかったのも、いろいろ作りたい人が出てきた理由だと思う。
ただ最近はきっちりと役割分担が出来ているので、もっとあっても問題ない。
501:login:Penguin
12/11/11 17:43:17.09 hvw58Qyv
煽り要素ゼロで言うんだが、「ext2の実装がひどかった」てすごいな…。
ファイルシステムの実装について評価できるやつがこのスレにはいるのか。
502:login:Penguin
12/11/11 17:57:57.77 mNzMe6Pv
十人いれば十人十色の需要があり、それに応えた/自分で開発した
ってだけでしょ。仕様公開してないNTFSのサポートだけが不完全ってだけで。
503:login:Penguin
12/11/11 19:11:03.72 2c3JORIq
>>501
ジャーナルが無かったので、システムがフリーズしたり、
停電の後、再起動が出来るか不安なファイルシステムだったよ。
504:login:Penguin
12/11/11 19:12:56.91 hvw58Qyv
不安定さはそうだろうけど、
ジャーナリングの有無なんてもんは単に仕様の話じゃね？
505:login:Penguin
12/11/11 19:14:06.30 as9ZdwRQ
そのジャーナルのお陰でext3は遅いけどな
506:login:Penguin
12/11/11 19:15:21.29 OLX557RM
それはext2の実装じゃなくて設計の話じゃないのか
507:login:Penguin
12/11/11 20:09:20.02 MEPnKq2m
minixのfsがウンコだったから作ったんじゃなかったっけ？
508:login:Penguin
12/11/11 21:33:15.34 qDC9w+h9
フリーズしたらマジックキー
停電はUPS使うだろ普通
509:login:Penguin
12/11/11 21:36:06.58 QIAgZ7z2
>>508
マジックキーって効かないこともあるんですけど
UPSなんて一般家庭にないんですけど
510:login:Penguin
12/11/11 22:19:40.90 as9ZdwRQ
一般家庭で使う事が限定の話だったの？
511:login:Penguin
12/11/11 22:22:41.98 3kaPvPl7
一般家庭でなくなったら困るデータとかないし
512:login:Penguin
12/11/11 22:27:00.81 QIAgZ7z2
だってLinuxはデータセンター専用OSじゃないもん
データセンターやUPSがある自宅鯖宅でも使われるけど
組み込みやUPSなし自宅サーバー
そして大きいのはデスクトップPC
としても使われる
一般家庭や企業のデスクトップPCにUPSなんてつけませんよ
513:login:Penguin
12/11/11 22:28:48.70 QIAgZ7z2
>>511
あるし
家族の写真とか
仕事の書類とか
コードとか
ムフフ動画とか
etc
514:login:Penguin
12/11/11 22:36:14.35 hvw58Qyv
UPSのバッテリが切れて、UPS機能失って単に電源タップとして使って早数年。
劣化したバッテリが溶け出してないか確認するのが怖い。
515:login:Penguin
12/11/11 22:38:21.86 KOknrrgB
家は貧弱だったのでリホームするまでUPS必須でした。
エアコンのサーモスタットがONするとPCがリブートするんだよなあ...
516:login:Penguin
12/11/11 22:51:23.87 OI+msgGo
UPSも冗長化しよう
517:login:Penguin
12/11/12 01:53:04.86 usLhJzvA
電力自由化がほんとに実現しちゃったら家庭でもUPSあった方が良くなるかもね
518:login:Penguin
12/11/12 01:53:10.22 p4TTgDL2
>>500
初代extがクソだったのでext2で再実装されたという話と混ざってないか？
519:login:Penguin
12/11/12 02:01:17.16 Mu3t822q
多様性だろ～
520:login:Penguin
12/11/12 02:13:13.49 06Vk+cuQ BE:512125632-2BP(1001)
ext2の時代は対抗馬のfatが恐ろしくクソだったけど
ntfs知ってしまうとアレだよな。ext4もbtrfsも中途半端って幹事
521:編集中のは失われて当然
12/11/12 02:59:34.62 UGWhY7R0
ntfsで動いているPCの電源コードを抜くのとext4で動いているPCの電源を
抜きそのまま再度何もせずに立ち上げたときどっちが何もしなくていいかで
評価するべきだよ。
ジャーナルファイルシステムとか言う以前にOSを含めた結果という事実が
重要になる。何もしなくて良いというなら1万回やって1万回同じ結果が
でるかを確認しろ！
#UPSとかsyncしないやつ&処理手順の言い訳。
522:login:Penguin
12/11/12 08:38:21.37 W2Pfq0dm
リブート時はsyncを3回ですね判ります
523:login:Penguin
12/11/12 08:53:45.05 CX737Rul
昔々、シングルユーザモードでSyncコマンドを実行すると、管理ブロックが
吹き飛んでしまうSUNのSoftware RAIDがあってね。（遠い目）
復旧は出来たけど、徹夜したっけな。
524:login:Penguin
12/11/12 17:37:15.29 8Qp/kenG
人生からXFSを除かば、世界から太陽を除くにひとし。
525:login:Penguin
12/11/12 23:26:50.03 xQbnJAl3
ext3,4の利点は再起動時のfsckが速いだけ。それ以外は全てにおいてext2の方が速い。
526:login:Penguin
12/11/12 23:40:27.82 WaGtjXoi
>>525
ジャーナル切ったベンチマークでext2よりext3が速くなかったっけ
527:login:Penguin
12/11/12 23:51:01.66 MTTZ8jKH
そういえばXFSもLinux由来では無いんだよな
SGI IRIXのをパクってきたんだっけか
528:login:Penguin
12/11/12 23:58:08.07 WaGtjXoi
>>527
SGIが移植したんだからパクりとは違う。
529:login:Penguin
12/11/13 01:13:48.21 b+E15Mqx
reiserfsとか
530:login:Penguin
12/11/13 03:38:06.23 D/TVeJeO
>>527
JFSもIBMがAIXのために開発したのがベースだよな。
531:login:Penguin
12/11/13 13:24:41.71 4hnSewz5
>>526
ext3にはジャーナル切れるモード無いだろ
532:login:Penguin
12/11/13 20:24:20.05 W3Xvs8tT
JFSとかXFSとかZFSとか、名前の付け方に芸が無さ過ぎ。
やっぱりvfatがクールだね
533:login:Penguin
12/11/13 20:30:49.76 Li2kj3Ue
日本初のファイルシステムがもしできたら
YAKITORI とか FUJISAN とかそういう命名しちゃうんだろうな。
534:login:Penguin
12/11/13 20:33:17.46 Li2kj3Ue
NILFSのこと忘れてたorz
535:login:Penguin
12/11/13 22:12:00.26 c6Gv8FFi
>>533
KOMADORIとかDOZEUとかの方がいいよね
536:login:Penguin
12/11/14 08:36:45.12 pwsZZAJP
aufsも日本人作だけど、普通のファイルシステムとは趣きが違うかな。
537:login:Penguin
12/11/14 20:24:11.63 UGegE3lQ
aufsは早くカーネルとマージして欲しい。
538:login:Penguin
12/11/15 05:19:36.12 Mm3MRx8E
URLﾘﾝｸ(gizmodo.com)
某ファイルシステム作った奴も殺人で転落したが、
セキュリティソフト作った奴も殺しで指名手配される時代になりました
539:login:Penguin
12/11/15 06:40:04.05 ug6bbry/
社名とか製品名に人名が使われてるとこういうときに怖いよなあ
540:login:Penguin
12/11/15 07:34:03.76 FjYmvev5
だから空母みたく全部エンタープライズみたいににしときゃよかったのに
541:login:Penguin
12/11/15 16:12:59.54 6jjEVyY7
そうなるとLinuxはこのままの名前だと大きなリスクを抱え込んでることになるのか。
542:login:Penguin
12/11/15 19:12:33.20 qQS2lqjV
Debianは黒歴史
543:login:Penguin
12/11/15 20:10:39.57 d0iNsTKG
Tomoyo Linuxとかな
544:login:Penguin
12/11/16 08:13:24.01 3ebm/7xg
人殺しのRiserは普通に使われてんの？
545:login:Penguin
12/11/16 22:08:16.24 OpER4CVb
普通に xfs も reiserfs も使ってるよ。
あと xfs 誉め殺ししてるヤツがキモい。
以前執拗に叩いてたのと同一人物だろ。
546:login:Penguin
12/11/16 22:11:10.14 KdowCz7z
>>545
みんなわかってるよ。
だから無視している。
547:login:Penguin
12/11/16 23:08:00.73 8YtSUCDX
最も軽くて速いのはreiserfs
548:login:Penguin
12/11/16 23:32:24.36 uLV1S0fd
うちのサーバでいちばん使ってるfsはcgroupだわ
# mount | awk '{print $5}' | sort | uniq -c
1 autofs
5 btrfs
9 cgroup
1 cifs
1 configfs
1 debugfs
1 devpts
1 devtmpfs
1 ext4
1 hugetlbfs
1 mqueue
1 nfsd
1 proc
1 rpc_pipefs
1 securityfs
1 sysfs
4 tmpfs
549:login:Penguin
12/11/16 23:51:04.33 xJSveBfa
ext4でなくbtrfs 使うメリットって何？
やっぱスナップショット？
550:login:Penguin
12/11/17 01:27:58.55 1BNr4K4i
ramfs最強
551:login:Penguin
12/11/17 01:46:01.81 hmwTkRqk
>>549
subvolumeが作れるとかsoftware RAIDがあるとか
552:login:Penguin
12/11/17 02:24:53.10 TonMVE3C
>>549
ラリー・エリソンにケツの穴までどころか身も心捧げられる
553:login:Penguin
12/11/17 02:48:32.34 ogziJxY2
ZFSっていつ主流になんお
554:login:Penguin
12/11/17 04:43:51.81 Q1mEG0vK
>>548
なんでバラバラで使うの？
555:login:Penguin
12/11/17 10:08:19.13 r562EpQO
>>548
何で29もマウントされてるの？
普通10もないでしょ
556:login:Penguin
12/11/17 10:17:15.99 hmwTkRqk
>>552
メインの開発者がもう逃亡してるから滑ってるよ
557:login:Penguin
12/11/17 10:25:41.27 yRzEMjtW
>>555
俺は26個だった
最近はcgroup関係とかusbfsとかそういうファイルシシステムじゃない
カーネルモジュールによってmountされてるものが多いな
558:login:Penguin
12/11/18 03:23:37.01 dP2pFDuU
>>557
フォーマット（区画がない）しないのにmountされることはないだろ。
カーネルに実装されていればmountされているというなら誰でもmountされて
いるというべき。
559:login:Penguin
12/11/18 06:36:03.12 J7i7lOLm
犬がマウントしてる
560:login:Penguin
12/11/18 09:58:36.51 SxCqCLu6
>>558
devfs
561:login:Penguin
12/11/18 19:19:00.32 3AJJp3i4
>>558
意味不明
nfsは？
562:login:Penguin
12/11/19 00:57:31.19 j1bL7btg
mountされている一覧にでてこないものをmountというのって頭変じゃね？
最低でもマウントポイントのディレクトリ作ってから家よ。
563:login:Penguin
12/11/19 17:01:23.90 DXm20sJ0
>>530
しかしLinuxのJFSはOS/2実装がベースなのだった。
最初のうちは「大文字小文字の区別ができない」とかそんな制限があったような。
564:login:Penguin
12/11/19 20:12:57.87 9Na0NKql
>>562
mount(2)システムコールを呼ぶ際に/etc/mtabに書き込むかどうかは
アプリに依るんだしそれは言い過ぎじゃね?
565:login:Penguin
12/11/19 20:35:23.74 AdHcY/+d
ここはmountについて語るスレではなくファイルシステムについて語るスレだ。
local,network,pseudoとくに限定してなさそう
566:login:Penguin
12/11/20 05:45:15.78 5COMWB25
[Phoronix] Linux 3.7 File-System Benchmarks: EXT4, Btrfs, XFS
URLﾘﾝｸ(www.phoronix.com)
567:login:Penguin
12/11/20 15:18:59.96 QR6MQbLl
>>530>>563
いやもともとOS/2でdevelopされて、その後LinuxとAIX。
OS/2以外ではcase insensitiveはoption。
568:login:Penguin
12/11/20 15:32:33.29 fiRGral6
JFSならAIXがオリジナルだろう
HPFSならOS/2だが
569:login:Penguin
12/11/20 16:28:21.32 QR6MQbLl
JFS1がAIX上。1990
大幅に改定されたのがOS/2上。これがLinuxとAIXに移植。1999
移植と並行してAIXが主開発場になって、1997
JFS2へ。2001
570:login:Penguin
12/11/22 21:08:48.48 aGVqJPfv
ZFSで冗長性なしでストレージプールを作成した場合
HDDが一台でも物理故障したらプール全体が死ぬという理解であってますか？
571:login:Penguin
12/11/22 22:08:52.69 V6Q46nve
>>570
合ってます。
一ファイルが複数台に分割されて書き込まれるので…
572:login:Penguin
12/11/23 12:39:37.99 DgCxL4o6
2040年問題 - HFSのタイムスタンプは2040年2月6日までしか取り扱えない。
2048年問題 - 2038年問題の1980年起点版。FATファイルシステムのタイムスタンプなどが1980年起点である。
2079年問題 - FATファイルシステムのタイムスタンプの起点の1980年1月1日を基点として、年数を下2桁だけで処理するソフトウェアなどは、その起点の99年後（2079年12月31日）までしか正常動作しない。
2108年問題 - FATファイルシステムのタイムスタンプは2107年12月31日までしか取り扱えない。
-----------------------------------------------------------------------
60056年問題 - NTFSのタイムスタンプは60056年5月28日までしか取り扱えない。
NTFSはいいとしてFATとかどうすんお
573:login:Penguin
12/11/23 12:56:19.65 pQi12ICh
FATの2048年とか2079年問題はファイルシステムの問題じゃないよね。
2108年問題はファイルシステムの問題かもしれないけど、あと90年もFATが現役かなあ？
2040年のHFSの問題はファイルシステムの問題かもしれんけど、古いMacなんか趣味でしか使われてないから問題なさそう。
574:login:Penguin
12/11/23 13:53:01.92 1DjkZ8PV
OSやAPがFSのタイムスタンプを符号あり扱いするように仕様変えれば
FSのブロックレイアウトは変わらないから68年先伸ばしできるお？
作りかえれないOSやAPはコードよりデータの寿命を優先してそれまでに捨てる
575:login:Penguin
12/11/23 17:45:22.26 zzuUWSlp
そんなのもはやFATとよべない。
おれの誕生日に作ったファイルかはるか未来のファイルに化ける。
576:login:Penguin
12/11/23 18:21:41.90 B796Zs33
2048年問題って聞いたことない
FATの精度が2秒だからそんなのないんじゃないの？
577:login:Penguin
12/11/23 21:06:42.92 unSoxewK
>>576
FATディスクフォーマットのタイムスタンプが累計秒数で記録されていると思ってないか
578:login:Penguin
12/11/23 23:43:26.49 B796Zs33
URLﾘﾝｸ(free.pjc.co.jp)
FATは年(7)/月(4)/日(5) 時(5):分(6):秒(5)と
カッコの数だけビットを割り当てて管理してるので
2048年に何か問題が起こるとは思えない
7bit確保されてるので1980+127=2107年まで大丈夫
でもDOSが内部的にどう時間を管理してるのかよく知らない
2048年に何か起こるんですか？
579:login:Penguin
12/11/24 00:31:42.14 PEn0woT6
>>578
ファイルシステム上は問題は起きないが、ファイルのタイムスタンプを1980年1月1日深夜0時ジャストからの経過秒数として32bit整数で保持しているプログラムが正常に動作しなくなる。
……ただし、そんなプログラムが実在するかは知らない。
580:login:Penguin
12/11/24 00:53:51.90 tmvWLVRx
DOSの時間系関数を使って管理してるDOSアプリには2048年問題は起こらない
ダメなのはC標準関数使ってるDOSアプリということですね
UNIXからFATをフォーマットしてる場合は48年以前に38年問題にひっかかるわけですし
581:login:Penguin
12/11/24 00:57:26.99 tmvWLVRx
×フォーマット
○マウント
582:login:Penguin
12/11/24 01:12:53.22 tmvWLVRx
いや、やっぱりC標準関数は1970年を基点とするからそれはないだろうな
FATで0x0000 0x0000というタイムスタンプのファイルがあったとして
それはエポック秒で315500400と変換されてしまうから48年問題は起こりそうにない
アプリで独自に符号付32bit値として保有してる場合だけに48年問題は起こる
こんなアプリ作ってる人いるんかいな？
583:login:Penguin
12/11/24 01:35:11.25 Khi9rNEZ
Linuxのmanpage見たら、ファイルの状態を取得する stat(), fstat(), lstat() 関数は、
ファイルの日時に time_t を使っていますね。
time()関数 ～ 紀元 (1970年1月1日00:00:00 UTC) からの経過時間を秒単位で返す。
も、返すのは time_t。
time_t をたどると正体は
/usr/include/bits/types.h:103:#define __SLONGWORD_TYPElong int
で 32bitのようですが、time_t を使うもの全般が、ファイルシステムに関係なくまずいのかな。
584:login:Penguin
12/11/24 01:39:16.07 Khi9rNEZ
>>583
くっついてるw
× > /usr/include/bits/types.h:103:#define __SLONGWORD_TYPElong int
○ > /usr/include/bits/types.h:103:#define __SLONGWORD_TYPE long int
585:login:Penguin
12/11/24 01:52:10.32 ynQbzFjy
time_tの正体が何かはシステムによって違うでしょ。
586:login:Penguin
12/11/26 11:57:20.62 5um68ud/
>>464
＞time_tはカーネルの64bit化とは関係なく、既に64bit化されてる。
まじで？
time_tが64bit化されたlibcのバージョン教えてくださいおねがいします
587:login:Penguin
12/11/26 17:41:47.54 fgUG4e/Q
GNU libcではtime_tはlong intであってlong intの大きさは処理系定義なので
まあきっとあってもおかしくはないとかなんとかかんとか
588:login:Penguin
12/11/26 17:55:27.87 kLZfMEml
32ビットでフォーマットされているものを突然64ビットで扱おうとして
データを壊しまくるファイルシステムｗ
589:login:Penguin
12/11/26 21:05:38.16 AuvtZE0G
>>586
＞>>464
＞＞time_tはカーネルの64bit化とは関係なく、既に64bit化されてる。
ubuntu 12 i386でsizeof time_tをprintしてけど32bitだ
590:login:Penguin
12/11/27 03:27:25.68 Z/NY1RrE
Ubuntuは32bitということですが
64bitに対応したLinuxディストリビューションはどれになりますか？
591:login:Penguin
12/11/27 04:23:12.75 Z/NY1RrE
あと初歩的な質問になりますが
32bitのLinuxからも、64bitのLinuxからも、
同一のファイルシステムをmountして問題なく扱えますよね？
例えば、ファイルのタイムスタンプの扱いが気になるのですが、
そこは、どちらにしてもファイルシステムの仕様通りに
きちんと処理してくれているということでしょうか。
592:login:Penguin
12/11/27 20:37:59.37 4DO8DdDv
Ubuntuにも64bitなかったっけ
マウントの問題は大丈夫
593:login:Penguin
12/11/27 21:02:09.58 yZTntV89
__STD_TYPE __TIME_T_TYPE __time_t; /* Seconds since the Epoch. */
594:login:Penguin
12/11/27 21:11:04.70 Z/NY1RrE
>>592
Ubuntuに64bitありますね
ありがとうございます
595:login:Penguin
12/11/27 21:17:04.40 eYUehpwt
#include <time.h>
#include <stdio.h>
int main(void)
{
printf("%d\n", sizeof(time_t));
}
8だった@Debian sid/amd64
596:login:Penguin
12/11/27 21:32:19.31 +FTMVYlJ
ちょww8ビットてww
597:login:Penguin
12/11/27 21:34:21.94 yZTntV89
8bytes
598:login:Penguin
12/11/27 22:03:33.10 2Faa51y/
>>595のやつ
Debian6.0.6@amd64(サーバー)
Ubuntu12.10@amd64(デスクトップ)
どっちも8でした
599:login:Penguin
12/11/27 23:05:11.14 P3Z6acGK
>>591
x86とAMD64で何が違うのかをもうちょっと知れば、そういう質問は出てこない気がするなあ。
600:login:Penguin
12/11/27 23:56:12.21 huHpR5/K
Linux vmware-virtual-machine 3.2.0-33-generic #52-Ubuntu SMP Thu Oct 18 16:19:45 UTC 2012 i686 i686 i386 GNU/Linux
Linux version 3.1.10-g22b4fcd (android-build@vpbs1.mtv.corp.google.com) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #1 SMP PREEMPT Fri Nov 2 10:55:26 PDT 2012
てもとだとこの2つはsizeof(time_t)は4だったが
>>464の
「time_tはカーネルの64bit化とは関係なく、既に64bit化されてる。 」
と矛盾してないのか？
601:login:Penguin
12/11/27 23:57:18.46 +wYW/dtS
>>599
32bitと64bitとしか書いてないからx86とamd64とは限らない。
というかその二つに限定すると理解が疑われかねんな。
602:595
12/11/28 02:17:16.58 nx7Okma8
なんとなく気になったので同じ環境で-m32つけたら4になった
ちうことで2038年までに64bit環境に移行すれという事らしい
603:login:Penguin
12/11/28 02:58:44.86 5vfkeZf4
>>601
「初心的質問」でそれ以外のアーキテクチャを
持ち出すだろうか？
604:login:Penguin
12/11/28 03:05:49.48 e8D1P1Xj
つかどう考えても>>591が言ってるのはamd64とi386のことだろ。
605:login:Penguin
12/11/28 06:17:15.56 0ObuYw3Z
ｽﾚﾘﾝｸ(tech板:620番)
スレ立てるまでもない質問はここで 122匹目で話題になってたけど、
アップデートしない組み込みLinuxはヤバそうだね。
606:login:Penguin
12/11/28 10:17:41.72 2fJdxEv6
単純な64bit化だと上4バイトは100年ぐらい使われないから
その領域を有効活用しようという輩がいるかもしれない
607:login:Penguin
12/11/28 10:35:01.64 x4Xy9KNd
>>606
COBOL世代とはビット単価が違うからなぁ
608:login:Penguin
12/11/28 16:42:42.18 C+kCIV84
アップデートしない組込環境ではtime_tうんぬん以前に脆弱性がやばい
609:login:Penguin
12/11/28 16:47:33.96 bHHFTT80
組み込みってネット繋がないじゃん
610:login:Penguin
12/11/28 17:24:41.82 lFI/pV4C
んなわけあるか
611:login:Penguin
12/11/28 20:12:30.97 U8I/LIIB
ext3では秒単位で2038年まで
612:login:Penguin
12/11/28 21:50:06.73 lh/AOkWt
ZFSの重複排除、当たり前だがメモリすげぇ食うな・・・
ファイル鯖としちゃあ便利な機能だがそんなにコストかけれないし重複排除は諦めるか
613:login:Penguin
12/11/28 21:52:57.70 hBeva0uk
メモリだけなら今安いから大したコストじゃないけど
CPUもそれなりのがいるんだろ？
614:login:Penguin
12/11/28 22:26:56.43 Ne5o68ud
>>612
なんで当たり前なん？
メモリーがたくさんいるのはなんで？
615:login:Penguin
12/11/29 00:04:45.98 o9n8bnB3
ファイル鯖にそんなCPU盛りたくないしねぇ。
ついでに他のアプリケーション動かせばいいんだろうが、なんにせよ個人じゃそんな鯖にゴリゴリさせる仕事がない。
重複排除とか圧縮かけても軽いくらいスペック盛るくらいなら、その金でHDD増設した方がいいんだよなｗ
616:login:Penguin
12/11/29 00:24:01.11 RhcfFgrp
重複排除ってどのくらいのスペックあれば快適に使えるの？
617:login:Penguin
12/11/29 08:11:56.67 5zmjOLOr
>>616
ZFSのrecordsizeによるけど、デフォだった場合、
データ1T辺り、重複排除だけで10G+ってオーダーでメモリーが必要になったはず。
L2ARCにSSDを用意しないと、メモリーから溢れた瞬間、とてつもなく遅くなる。
CPUよりメモリーの方を何とかしないとダメ。
618:login:Penguin
12/11/29 16:13:34.55 rgKmcfFs
>>612
l2arcの出番じゃね？
619:login:Penguin
12/11/29 18:36:14.17 ELpMFPV8
同一内容を検索・識別するんじゃなくて、
ファイルコピー動作とかを認識して重複排除するとかできないんだろうか？
最近読みだしたデータに限って同一判定するとか。
620:login:Penguin
12/11/29 18:54:19.39 UP0NKDBj
>>619
よく意味が分からんけど
書き込みが発生したときにブロック単位で同じのがあるかどうかを見るんじゃないの
そのテーブルがメモリをバカ食いするってことだと思うけど
621:login:Penguin
12/11/29 18:55:27.61 5r3O4WuD
それただのCoWじゃねーか？
NAS上で完結する世界ならそれでもいいけど、実際に求められてるものとは違う
622:login:Penguin
12/11/29 19:48:42.51 0qHQtO7n
重複判定できるってことは、そのぶん余計なメタデータを読み書きしないといけないんだから性能落ちるよね
623:login:Penguin
12/11/29 20:48:15.45 pjalMcgj
重複排除によって無くなった行われるはずだったユーザーデータの書き込み量のほうが多いかもしれない
624:login:Penguin
12/11/29 20:57:57.56 8G72Uq2S
>>623
クラウド、VPSの仮想HDDの中の/bin以下のファイルみたいなかなり特殊な用途？
625:login:Penguin
12/11/29 23:13:38.69 pDJO4XkO
XFSを褒め殺しにしていると疑われているオレ様がやってきましたよ
褒め殺しではない
純粋に褒めているし実際に使っている
叩いた事など神に誓ってない
ZFSなら叩きたい
626:login:Penguin
12/11/29 23:19:38.18 Fy7iUFEH
そっか よかったね
627:login:Penguin
12/11/30 07:52:53.99 +IUiRuU3
XFSとZFSの良いとこ取りの新ファイルシステム YFS
628:login:Penguin
12/11/30 11:19:43.24 O6Mkk6WA
>>619
特定の状況だけ適用してもらいたいんならその状況時にユーザーモード側でioctl発行しろと返されんのがオチ
629:login:Penguin
12/11/30 13:06:34.15 MBudbpC1
>>618
HDD増やした方がコスパよくね？業務に使うならともかく個人ならな
630:login:Penguin
12/11/30 13:20:22.58 97UtYzmP
同じ形式のファイルをテラ単位で扱うような用途じゃないとあまり恩恵はないだろうな
少なくても自分は容量食ってるのは動画とか音楽とか写真だから全く意味無い
631:login:Penguin
12/11/30 14:41:02.44 +IUiRuU3
仮想マシンのファイルはほとんど同じなので、
重複排除でバンザーイと思って、Virutalboxと
ZFSの組み合わせを試してみた事がある。
ほとんど重複排除の効果は無く、一時停止で保存した
ファイルでゲストOSが再開できないとか、逆の意味で
バンザーイの結果だった。
632:login:Penguin
12/11/30 14:45:50.73 XBMblfhY
世代バックアップとか
633:login:Penguin
12/11/30 19:14:17.65 +U2+nr9a
ハードリンクで済むような
634:login:Penguin
12/11/30 20:43:12.76 c5zYVaPD
大きいファイルの世代バックアップには有効そうなんじゃない?
何ギガもあるsqliteファイルとか。
635:login:Penguin
12/11/30 20:46:57.15 +d+9eytJ
バックアップになってるのかそれ
前にもそんな議論があったような
636:login:Penguin
12/11/30 20:50:49.19 Wbr1Hrjf
まあ核攻撃に耐えられなければバックアップとは言えないからなあ
バックアップでないものをバックアップと言う人が多いよ
まったく
637:login:Penguin
12/11/30 20:56:39.55 +d+9eytJ
前の議論もそうだけど
勝手にバックアップのハードル上げてるだけだと思うが
638:login:Penguin
12/11/30 21:21:07.01 cH0j9TJP
月面データセンターだと万全のバックアップできる
応答時間に数秒要するからバックアップにしか使えないけど
639:login:Penguin
12/12/01 11:06:30.84 57GOA1iw
月は出ているか？
ってガンダムXごっこができるな。
スペースデブリの月面DCへの影響は無視してもいいよね。
640:login:Penguin
12/12/01 11:11:57.60 u17Es2jQ
電磁波って宇宙だと減衰しないから
宇宙に向けて全データを電磁波の形で発信しておけば
少なくともこの宇宙がなくなるまでは保存されるな。
641:login:Penguin
12/12/01 11:43:54.49 N7ftY3AP
>>640
その発信したデータを読みたければ、電磁波より速く飛んで先回りして受信しなければならないのでは
642:login:Penguin
12/12/01 12:13:10.05 NaDxh72b
え？ｗ突っ込むとこそこかよｗｗ
文系かよｗ
643:login:Penguin
12/12/01 15:37:17.27 RSbxRGIT
ZFSの重複排除ってメモリに蓄えるから、
不意の電源OFFだと全部破壊されちゃうんだよね
それだとバックアップに使うのは怖いな
644:login:Penguin
12/12/01 15:39:14.11 YCftnAyr
んなわけない
645:login:Penguin
12/12/01 16:17:37.35 ahLWJFql
>>643みたいな幼稚な人が作ってるファイルシステムあったら教えて下さい。
646:login:Penguin
12/12/02 11:30:19.75 7/pq8/aL
>>640
波長によって激しく減衰する、宇宙は完全な真空ではなく万年やら億年
経過したそれが何も影響しないというのはアフォ。
647:login:Penguin
12/12/02 19:04:34.13 mVabdcTi
>>645
ZFS
648:login:Penguin
12/12/02 23:00:00.47 rtnvhs7J
ファイルシステムとバックアップは分けて考えなければいけない
649:login:Penguin
12/12/03 00:59:53.94 NL3l4q/N
分けて考えないのが近年の高機能ファイルシステムでしょ！
650:login:Penguin
12/12/03 02:01:26.58 m+hsgesp
>>649
って誰が言ってるの？
651:login:Penguin
12/12/03 07:50:17.46 XMtYyBax
俺だよ。この俺が言ってんだし間違いない。
652:login:Penguin
12/12/03 09:12:19.30 IatjFUis
この前、自分定義のバックアップって言葉使って馬鹿にされた馬鹿が
粘着してるなぁ。
653:login:Penguin
12/12/03 19:51:06.32 jsdeVSEB
>>651
ソースは2ch (笑)
654:login:Penguin
12/12/03 20:16:29.29 OnmaiFIf
その時馬鹿にした連中の方が勝手な定義してたな
655:login:Penguin
12/12/04 02:47:31.73 /MyXzNsh
しつこいよ
656:login:Penguin
12/12/04 11:58:42.03 0MaVXl3z
>>654
お前、本当に馬鹿なんだな…
657:login:Penguin
12/12/04 12:10:59.15 4OSV5gGC
定義なんて話の都度擦り合わせればいいのよ。
658:login:Penguin
12/12/04 12:19:44.14 /MyXzNsh
はいはいビールジョッキ思想
659:login:Penguin
12/12/07 03:38:12.68 Kmapfwof
zfs-win - ZFS for Windows
URLﾘﾝｸ(code.google.com)
あるにはあるんやな
660:login:Penguin
12/12/11 10:48:11.30 OC3w0rBs
ZFSのファイルシステムにMysqlのデータを置いた環境があり、
某システムの評価で圧縮して400MバイトのMysqlのダンプファイルを
インポートしてみた。
平時はあまり使われない、Logsの領域にも激しく書き込みがあり、
Logsのallocの領域がみるみる増えて行く。raidz1のディスクで30MB/sec
Logsの30MB/secと合計で60MB/secの書き込みが出来て、ZFSの
実力の一部が判った。
661:login:Penguin
12/12/11 20:46:17.33 xycx3/qX
XFSが3.7でinode64がデフォルトになるから3.6以前に持ってく時は気を付けろー
URLﾘﾝｸ(kernelnewbies.org)
662:login:Penguin
12/12/24 22:27:48.15 sbyUtyUS
なんでext4には作成日時のタイムスタンプがないの？
663:login:Penguin
12/12/24 22:40:45.97 E6q8YXZl
>>662
いや、あるよ。
664:login:Penguin
12/12/24 23:08:00.12 eKE+nVHw
ctime無いのはFAT位でないかい
665:login:Penguin
12/12/25 00:49:11.63 1QXwWvF5
ctimeってリンク数増やしたりとかしたら変わらないかい
666:login:Penguin
12/12/25 01:24:41.49 nEcZEp+3
それはmtime
667:login:Penguin
12/12/25 10:35:35.06 IP+RDtTj
ZFS Linux Native RC13が出てました。
いろいろ直っているみたいだが、ウチの
自宅サーバでは何の問題無く動いているので、
違いが判らん。
668:login:Penguin
12/12/25 11:38:28.45 h2WGgx8H
ctimeとcrtimeは混同してはいけない
669:login:Penguin
12/12/25 11:43:42.21 Y1A2QGKN
birth time があるよ
670:login:Penguin
12/12/25 12:05:30.52 XahNtSbC
>>666
誤り
mtimeが変わるのはファイルの内容を書き換えた時
リンクカウントの増減はメタデータだけの変更に当たる
671:login:Penguin
12/12/25 15:42:44.80 p7dp1Rj6
ctime をファイル作成日時だと勘違いしてるやつがいるのか?
672:login:Penguin
12/12/28 05:03:18.35 Isi4WQd9
NTFS ボリューム上で新規ファイルが作成できない現象について
URLﾘﾝｸ(blogs.technet.com)
$Secure のデータは少しずつ登録される事が多く、非常にフラグメントが発生しやすい環境です。
$Secure のフラグメントが解消される事で、登録できるセキュリティ記述子の数が増える事が期待できます。
Windows7 / Windows Server 2008 R2 以降の環境で発生した場合には、まずはデフラグの実施をご検討ください。
※ 現在、Windows 7 / Windows Server 2008 R2 環境でデフラグを実施したところ、反対に $Secure の File Record 数が増えてしまったという報告を受けています。
詳細が確認出来次第この記事をアップデートいたしますので、それまで $Secure の ATTRIBUTE_LIST を減らす事を目的としたデフラグの実施はお待ちください。
;(；ﾞﾟ'ωﾟ');
673:login:Penguin
12/12/31 04:28:13.37 dAiNz+QV
raidz や raidz2 で、玉を増やすほうの grow が出来るようにならないかなあ。
674:login:Penguin
13/01/01 21:53:27.45 Nww2FIpd
>>672
その地雷を最初に踏んだ人がどれだけ悩んだか
話を聞いてみたい
675:login:Penguin
13/01/06 23:12:39.85 kYUtqyri
重複排除と透過圧縮とファイルのチェックサムの機能がある
ファイルシステムってZFSだけでしょうか?
調べてみるとlessfsは重複排除と圧縮機能があるみたいですがチェックサムはなさそうで
ext4とbtrfsは圧縮とチェックサムがあって重複排除はない(btrfsは実装予定?)みたいです
676:login:Penguin
13/01/06 23:35:38.20 Re23CH8E
>>675
URLﾘﾝｸ(en.wikipedia.org)
677:login:Penguin
13/01/07 10:19:35.98 0RviA27S
ext4のチェックサムってメタデータだけでしょ
678:login:Penguin
13/01/07 12:19:52.72 AWuj5r3N
データが化けてもメタデータさえOKならファイルシステムの整合性は完璧だからな。
679:login:Penguin
13/01/07 20:13:16.34 ZaqHohDc
ファイルが壊れてもファイルシステムが壊れなければ意味があるっ
680:login:Penguin
13/01/07 21:30:47.50 zbCcU4Hg
raid5+xfsでデータ化けするて聞いたんだけど
raid5で1ディスクの1ブロックだけ化けた場合でも修復できないんだっけ？
681:login:Penguin
13/01/07 22:40:40.63 RNyulshO
釣りか？ ソフトウェアRAID だろうが、ハードウェアRAID だろうが、RAID5 と
ファイルシステムではレイヤーが違うから「RAID5+xfsでデータ化ける」なんてことはない。
データが化けるのは別の原因で xfs 以外のファイルシステムにしたときに、たまたまその
ブロックを踏まなかったってだけだろ。
この場合ハードウェアRAID が何らかの故障を抱えているんだと思う。
ただ、アクセス速度を上げるために、パリティチェックしない製品／設定がある
(ハードディスクに全くアクセスできない場合のみパリティから修復)らしいので、
「raid5で１ディスクの１ブロックだけ化けた場合でも修復できない」事はありえるが。
682:login:Penguin
13/01/07 22:57:19.54 zbCcU4Hg
ディスク3台で A,B,パリティ になってる所で
パリティ部分がデータ化けしたらそのブロックは修復できんの？
683:login:Penguin
13/01/07 23:57:05.50 JEVZzUqP
RAID5ではどっちみち化けたら修復できない。どっちが正しいか判別できないからだ。
RAID-Zなら別だがな。
684:login:Penguin
13/01/08 00:00:55.60 8lDKm/Dg
なるほどね、勉強になった
685:login:Penguin
13/01/08 00:28:39.57 Atou43r/
1ビットのパリティは1ビット以内の誤りを検出できるだけだからな。
化けられたらどうしようもない。
運を天に任せて1台切り離せば読めるかもしれないぞ。
686:login:Penguin
13/01/08 10:29:38.66 /ogJNGIY
エラーにならずにデータ化けってありうるの？
HDDにCRCが付いてるだろ。
687:login:Penguin
13/01/08 19:40:17.92 KdksbYEC
何もせずとも、いつの間にかデータが書き換わってしまうことはありうる。
そのため最近の RAID 装置は、「書き直し」ジョブが定期的に走るようになってる。
688:login:Penguin
13/01/10 16:11:44.04 gRqgAReQ
HDDは10^-13から10^-16。RAMは10^-10から10^-17。NWは10^-12。
なので1[PB]とか読み出したら、上位（RAMならECCとか）でチェックしない限り確実に誤データが入り込むんでない？
689:login:Penguin
13/01/10 23:26:59.15 r/7w+A81
>>683
btrfsのRAID5も、実装されたら修復できるようになるんじゃないかな。
出る出るといわれ続けてもうすぐ4年経つんだっけかw
btrfsではデータブロックのチェックサム(CRC)を記録してるから、
化けたブロックは特定できるはず。
どのデバイス上のブロックが化けているかが分かれば、
残りのデバイス上のブロックからXORでブロックの中身を計算して
書き戻せば修復できるはず。
もっとも、RAID5以前に「読み」「書き」以外のことをすると
高頻度であっさりハングする不安定さをどうにかすべきだと思うが。
690:login:Penguin
13/01/11 15:26:03.19 inrpPmjz
brtfs捨てて、ZFSのライセンスを見直すだけでいいんだけどなぁ
691:login:Penguin
13/01/11 17:49:24.05 oxVyIfiF
ZFSはクローズドソースになっちゃったんじゃないの? FreeBSDは、オープンソースの最終版からフォークしたような…
692:login:Penguin
13/01/11 23:01:57.29 F3CrXeKc
Linuxファイルシステムの進化ももZFSがクローズドでは、もう期待出来ないね。
真剣にNTFSライセンスの購入を検討した方がいいんじゃないの？
693:login:Penguin
13/01/11 23:07:04.30 lbTcwCRM
>>692
ZFSはlinux界隈じゃなくてUNIX界隈だから関係ないよ。
694:login:Penguin
13/01/11 23:48:58.03 juyFHRgg
クローズドからオープンになった事例は結構ある。
ってかオラクルは何でクローズドにしたんだろ。
695:login:Penguin
13/01/12 00:16:46.64 aNxW0D7F
>>694
ライバルを買収して相手製品を死蔵して潰す場合と、
ライバルを買収して相手製品を自社で売る場合がある。
オラクルには独自のFSがあるんで、死蔵させて潰す選択をしただけ。
696:login:Penguin
13/01/12 00:46:35.27 0Z5ZsCEg
>>695
> オラクルには独自のFSがあるんで、死蔵させて潰す選択をしただけ。
何言ってんだ? Solarisで使ってるだろ。
まさかbtrfsのことじゃないか?
697:login:Penguin
13/01/12 04:13:36.30 BOSy2gR3
ZFS Storage Applianceとか全然売れてねぇけどな
遅すぎるわ
698:login:Penguin
13/01/12 10:26:25.88 Y5noCBqR
商用ファイルサーバなら既にIsilonがあるしなあ。
699:675
13/01/12 15:01:50.21 cOhIruVB
調べてみるとbtrfsも重複排除はできるようでした
URLﾘﾝｸ(btrfs.wiki.kernel.org)
でもこれWindows 2012のNTFSのデータ重複除去と同じく
書き込み時に重複排除してくれるものではなさそうです
700:login:Penguin
13/01/12 15:42:52.09 KIJWX0q5
btrfsでその手の付加機能使うのは、まだ怖すぎる。。。
やっぱFSみたいな物は、昔から言われてるけど、企業がお金かけて作らないと
厳しいねぇ。
ドッグフードをガシガシ食って、主要部分だけでもバグ潰ししないと、いつまで経っても、
ドッグフードのまま・・・
701:login:Penguin
13/01/12 16:22:29.70 Q49Svj5w
zfsでいいからgrowつけてー
702:login:Penguin
13/01/12 16:36:35.20 cOhIruVB
btrfsの重複排除は使ってるっていう情報が見当たらないですね
重複排除と透過圧縮とファイルのチェックサムがあって
わりと使われていそうなのはZFSだけみたいなんでZFSを使ってみることにします
703:login:Penguin
13/01/12 17:43:29.86 uRAkZkwX
なんでみんなZFSなんだよ！
Linuxには、ext4っていう最先端技術が一杯盛り込まれた優れたファイルシステムがあるだろう？
704:login:Penguin
13/01/12 20:28:12.35 3vA9nSNa
ORACLE様ならbtrfsやZFSなんての無視してASMでいいやん
705:login:Penguin
13/01/12 21:07:33.39 cOhIruVB
>>677
ext4 のチェックサムはメタデータに対してなんですね
何か勘違いしてました
ZFSでもファイルデータの修復ができるのはRAIDZとかで冗長化している場合だけですよね
ファイルのデータに対してチェックサムじゃなくて誤り訂正符号が
付けられるファイルシステムは聞いたことないですし
もしかして3-way mirrorかRAID6なら(そんな頻繁に起こると思いませんが)データ化けが起ころうが訂正できるのかな
いずれにせよlessfsってのとbtrfsの重複排除機能の情報は少ないのでZFSにしてみます
706:login:Penguin
13/01/12 21:28:17.87 eknoUllv
そんなに誤り訂正欲しきゃ
RAID5+0でもRIDE6+0ででも組めばいいのに
707:login:Penguin
13/01/12 21:33:42.79 3Cj8wb7m
>>703
zlib圧縮すらstableでないfsじゃぁねぇ…。
708:login:Penguin
13/01/12 21:43:08.44 LY2IsmYi
RAID6も故障Diskが既知でないと訂正できないみたい。
正直、データの整合性はHWに任せてOKと思うんだけど…
709:login:Penguin
13/01/12 21:44:47.86 b65AxsL8
>>707
stableじゃない事がなんなんだ！
皆でドッグフードの不味い部分をもっとガツガツ食べようぜ
710:login:Penguin
13/01/12 22:54:07.82 cOhIruVB
誤り訂正はできたら良いなってところで
透過的圧縮と特に重複排除が優先して使いたい機能です
lessfsで良いじゃないかってところなんですが情報が少なくて躊躇してます・・・
よく考えたら3-way mirrorやRAID6にしようがファイルの読み出しで
きっと毎回全部のディスクからデータを読んで比較なんかしてないですよね
mdadm はそんな設定があるのかな?
ZFSはファイルを読んだときにチェックサムが合ってなければ
RAID-Zから復旧してくれるんだろうと思います
711:login:Penguin
13/01/13 02:46:29.73 NAAHtUCC
>>710
おまえがそもそもRAIDがなんなのかすら理解できていないことは理解できた
712:login:Penguin
13/01/13 07:41:59.28 UZ72D32g
面倒くせーな…
だったらEMCでも買えよ
713:login:Penguin
13/01/13 09:20:57.78 vcbLXZXa
>>710
RH系だとraid-checkってスクリプトがスケジュールに登録されてて
週一でアレイの整合性チェックが実行されるはず
mdが内部でどんな処理してるのかまでは知らないけど
確かにRAID6なんかでデータ部の修復までしてくれたら嬉しいわな
714:login:Penguin
13/01/13 10:11:21.77 cyAX9XCn
気にしすぎなんじゃないかと思うが
715:login:Penguin
13/01/13 10:16:16.87 cyAX9XCn
>>710
mdadmにそんな仕組みはないみたいだぞ
URLﾘﾝｸ(serverfault.com)
URLﾘﾝｸ(www.spinics.net)
もしディスク間で書かれているデータが異なっていたら
checkでmismatch_cntが増える
URLﾘﾝｸ(tkyk.name)
で >>682-683 のとおりRAID1(2-way mirror)やRAID5なら
どちらが正しいか分からない
3-way mirrorやRAID6なら修復できるのかは知らないけど
重複排除を使いたいならZFSで良いんじゃないか？
716:login:Penguin
13/01/13 10:42:31.20 nef7rk8V
どんだけ大容量のファイル使ってんだかしらんが
数世代前でも無い限りRawデータだってCRCぐらい付いてるだろ
717:login:Penguin
13/01/13 14:26:41.53 WNNbjCZH
まず、HDDにはセクタ単位でECCがついている。
このため、かなりの数のbitが同時に都合よく化けない限り、エラー訂正できる。
(もちろんエラーが、検出は出来ても訂正は出来ない場合にはリードエラーとなる)
そして、これは推測だけど「訂正可能なレベルのエラー」の中で、ある程度の回数だとかbit数だとかの規定値を超えたら
それはファームにより「不良セクタ」としてマークされ、代替処理が行われると思われる(OSからは見えない)。
一方、RAID456で使われているのは「パリティ」で、これは誤り訂正も出来ないし
エラー検出能力もきわめて低い。
しかし、「欠損」つまりどこのbitでエラーが起きたのか確実にわかるケースに限定すれば
正確に補完する能力があり、容量効率も良い。
これの欠損が、物理的な故障にぴたりとあてはまる。
718:login:Penguin
13/01/13 14:27:24.11 WNNbjCZH
というのが俺の認識。
719:login:Penguin
13/01/13 17:12:42.97 bhCnZe/+
CRCと言っても幾つもあって、訂正できるのもある。
訂正できるものでRAIDで使われているものもある。
720:login:Penguin
13/01/13 17:22:37.59 brteRuyx
なんでZFSスレ すぐdat落ちしてしまうん？
721:login:Penguin
13/01/13 22:28:03.82 DWH82Koe
>>717
つ URLﾘﾝｸ(ja.wikipedia.org)
722:login:Penguin
13/01/13 22:31:47.15 DWH82Koe
RAID-5・6の欠点はパリティ更新時の障害によるサイレントクラッシュであって、
パリティの算出手法そのものには、まあ問題ない。
723:login:Penguin
13/01/13 22:43:13.74 ZgpfrF9Q
そこまでRAID5やRAID6に不満や疑義あるならEMCでも使えばいいじゃん
724:login:Penguin
13/01/13 22:44:30.77 2ej4YTvr
>>721
708でも書いたんだけど、エラー位置が既知の場合しか訂正できない様に
読めるんだけど。
普通はそういうのは誤り訂正符号とは言わないと思う。(個人的感想)
これを誤り訂正可能というなら、ただのパリティも誤り訂正可能だよ。
もちろん世の中すべてのRAID6の実装を知ってるわけでなく、wikipediaの
記述に関してだけ言っています。
725:login:Penguin
13/01/14 13:16:39.96 pwCvoTNK
>>724
それが所謂サイレントクラッシュな訳だが。
誤り訂正符号で治せないのと、破損位置が分からないのは、
別の問題じゃねーの。
726:login:Penguin
13/01/14 15:29:49.71 Ro+YnSj9
>>724は、>>717に対する>>721の良く分からないコメントに(横から)レスしました。
ECCと呼ばれるものはエラー位置が未知の状態で訂正します。
(パンクチャ/デパンクチャしたりもしますが…)
ECCでは、エラー位置が分からないのと訂正不能なのは同じ問題です。
ECCを採用するのは符号化率や計算能力とのトレードオフになるので、
エラー位置が分かることになっているRAIDでは採用しないのも当然と思います。
727:login:Penguin
13/01/14 17:06:21.54 rDvtV583
> ZFSでもファイルデータの修復ができるのはRAIDZとかで冗長化している場合だけですよね
RAID Z でないものも zpool scrub かけてエラーがあった場合に
checksum からなんとかできる程度の修理はしてくれる > ZFS
限界はあるけど．
っていうかどの程度までリカバリしてくれるのかは良く知らないのだ
728:login:Penguin
13/01/14 18:58:42.94 bX8WHOA5
ZFSならmirrorからでも修復は可能
あと複数Diskで冗長化してなくても、zfs set copies=xでファイル書き込み時に同一Disk内の複数の箇所に分散コピーできる
素直にHDD増やした方がいいけどね
729:login:Penguin
13/01/15 11:09:35.36 yizzDlNT
>>720
話すネタがないから。
730:login:Penguin
13/01/16 08:46:39.55 U38Qvbzd
zolってどーなってるの？
731:login:Penguin
13/01/16 17:12:46.94 yaz60tN6
ReFSってもう一般向けでも使えるんだな
URLﾘﾝｸ(www.k-php.com)
732:login:Penguin
13/01/16 20:26:34.41 abhWrCo8
>>731
Windows Server 2012からね。
今のところWindows8とかのクライアントOSには載ってないよ。
重複除去使いたいからNTFS使ってるけど(´・ω・｀)
733:login:Penguin
13/01/16 21:07:05.97 1egIPtvs
ZFSとbtrfsって比較してる奴は……勝負になると思ってんのかなぁ？
全然違うじゃない
……名前の格好良さが！
（SunとOracleの信頼の差というのと、初出の安定感とかもあるけどさ！使いたい技術ってまず名前で決めるじゃない！）
734:login:Penguin
13/01/16 21:09:21.32 evfYGKa7
巣に帰ってどうぞ
735:login:Penguin
13/01/16 21:11:17.91 abhWrCo8
Btrfsってあと何年でstableになるんだろう。
ZFSのRaidzは数増やせないから不便で不便で(´；ω；｀)
736:login:Penguin
13/01/17 00:05:11.89 jsQiDD7x
速度的には同じくらいなん？
737:login:Penguin
13/01/17 00:07:52.99 c2HKR1nc
ZFSと比較はしたことはないがスナップショット取るとIOが固まるとか
スナップショットを削除するとIOが固まるとか時々deadlockが発生するとか
速度以前の問題。着実に改善はされてるがまだまだ。
738:login:Penguin
13/01/17 09:28:19.77 MiqQ2KX8
ext5のが先にくるよ
739:login:Penguin
13/01/17 10:30:03.06 5x9z15k4
fedora18ででたファイルシステムってどうなの？
740:login:Penguin
13/01/17 10:48:42.26 2Vd5P3iH
>>739
なんていうファイルシステム?
741:login:Penguin
13/01/17 10:50:04.67 /E/SOxqL
>740
btrfsでしょ
昨日やってみたよ
742:login:Penguin
13/01/17 10:56:35.01 2Vd5P3iH
FedFS のことかな。
>>741
btrfs は前からなかったっけ。
743:login:Penguin
13/01/17 13:21:54.21 rZx4pOd9
dragonflyBSD hammerの方が着実に実績を積んでる
744:739
13/01/18 00:42:49.27 nOSdqiD+
>>741
ググってから発言してくれ頼む
>>742
うん、それ
うちではインストールが途中で止まったから諦めた
745:login:Penguin
13/01/18 08:56:29.52 Nz5w3DJD
>744
そうですか
btrfsを選択してOSをインストール出来るようになったのはfc18からじゃない
746:login:Penguin
13/01/18 09:54:36.26 PpjrVu+E
>>744
ファイルシステム名くらい最初から書けよ……。
747:login:Penguin
13/01/18 11:35:37.27 4NJs1YxA
アホ二人
748:login:Penguin
13/01/18 17:15:33.73 BFXIKgWW
ReFS Activator for Windows 8
URLﾘﾝｸ(www.firstever.eu)
;(；ﾞﾟ'ωﾟ');
749:login:Penguin
13/01/19 10:57:58.65 R6RWsy4T
Server 2012のシステムファイルをそのまま配布しているので真っ黒
750:login:Penguin
13/01/20 10:10:02.22 amUzvKOm
そもそもボラクルにやる気があるのか
751:login:Penguin
13/01/20 15:44:03.92 yDphgzgh
>>750
btrfsのことならメイン開発者はもうオラクルにはいないぞ
752:363
13/01/20 20:51:21.82 VrfUmOPB
なに！
ならもうBtrfsはオワコンなのか
753:login:Penguin
13/01/21 07:14:24.40 yz7bYEb+
始まってすらいなかったような・・・
754:login:Penguin
13/01/21 13:06:17.13 jnnTl6z+
早くbtrfs捨ててZFSを突っ込めばいいのに……
755:login:Penguin
13/01/21 14:09:16.43 dTBknlPR
FreeBSD, OpenBSDと共同で、OpenZFSとか作れないものなのかしらん。
ライセンスは、GPLv2とBSDのデュアルライセンスで
756:login:Penguin
13/01/21 14:34:32.36 R33gZhm2
また初めから実装するのは無駄だしBSDと共同はないだろ
757:login:Penguin
13/01/21 16:28:38.22 +enGwRpV
その方向ならHAMMERとかどうなん。使ったことないからよく知らないけど。
758:login:Penguin
13/01/22 00:32:05.83 esLDsH/r
HammerをOpenBSDやデフォルトにしてほしい
759:login:Penguin
13/01/22 14:17:27.15 IV9dmsLb
だからZOLどうなってンのよ。
760:login:Penguin
13/01/23 01:06:06.96 ogQ2qGXu
>>759
一向にstable出ないけど1,2ヶ月にいっぺんくらいはrc更新されてるよ。
761:login:Penguin
13/01/23 11:33:57.90 4gDUZnvC
FUSEベースのMicrosoft「exFAT」実装、「fuse-exfat 1.0」がリリース
URLﾘﾝｸ(sourceforge.jp)
762:login:Penguin
13/01/23 17:31:15.42 4BudqjbT
>>760
返信ありがとう。気長にstable出るの待つかあ。
>>761
これでさらにexFAT/GPTで起動が出来れば、
USBメモリがより安全になり使い道広がるんだが。
763:login:Penguin
13/01/28 08:15:07.80 GZk0n1tK
Windowsに他ファイルシステムを使えるようにするフリーソフトは何故ないの
764:login:Penguin
13/01/28 09:46:12.22 1JCvRlM8
>>763
何故無いと思うの？
765:login:Penguin
13/01/28 14:10:54.28 A2Y2E2A+
Win版FUSEであるDokanもあるし、何が無いんだ？
766:login:Penguin
13/01/29 10:00:01.90 jDJUY4NR
DokanてWin8未対応じゃなかったっけ
767:login:Penguin
13/01/29 13:59:41.92 aKG9Xclb
互換モードでインストールできて動くんじゃなかったっけ
768:login:Penguin
13/01/29 14:07:20.03 s2x0j8Xb
つか、>>765-767のやり取りこそ>>763の思う壷だろ
769:login:Penguin
13/01/29 14:08:09.12 OC0WG3ry
何かまずいか?
770:login:Penguin
13/01/29 14:25:02.25 JmjWVhoC
煽りメソッドとかいう下らないのだろどうせ
771:login:Penguin
13/01/29 22:09:59.19 sH/w0jmy
Dokan上でencfs4win動かしたらなんか動作が怪しかった
772:login:Penguin
13/01/31 01:08:56.64 imwQWOHv
ext4をWinで使いたいです＞＜
773:login:Penguin
13/02/02 20:46:12.53 Zh/i4pOX
zfsで定期的にスナップショット取ってるんですけど
スナップショットから特定のファイルだけ削除することは出来ますか？
774:login:Penguin
13/02/04 14:15:17.51 mA+a2FZk
この記事がすごくおもしろかったんだけど、
【清水理史の「イニシャルB」】 予想以上に便利な記憶域スペースやSkyDrive連携
Windows 8＋NUC＋Thunderboltで作る自宅サーバー - INTERNET Watch
URLﾘﾝｸ(internet.watch.impress.co.jp)
win8の「記憶域スペース」と同等なことをLinuxで実現できるファイルシステムってあるのかな？
いまはLVMで 1TBのHDDを4本束ねて 4TBのボリュームを1つ作っているけど、
どれか1つでもHDDが欠けると、ボリューム全体が見えなくなってしまうよね。
ZFSは、ソフトウェアRAIDとLVMの「あいのこ」みたいな認識を持っているのですが(私の不勉強でしたらすみません)
ZFSは、Raid1をやりつつオンラインで領域拡張をしたり、ボリュームを構成しているHDDの一台が壊れても、
マシンを止めたりファイルシステムをアンマウントせずともHDDの付け替えとかできるの?
775:login:Penguin
13/02/04 16:29:42.30 w3v5aG/Y
>>774
Linux NativeのZFSを使ってるけど、
1T4本なら3Tのディスクが確保できるよ。RAIDZ1というキーワードで
google検索すると、機能の説明や設定方法がいろいろ出ているので、
そちらを参照。
オンラインで切り替えが出来るか、自分も不勉強だったが、SATAのコネクタは
OSが起動中に抜き差しが出来るみたい。年末に会社の備品の整理をした時、
大量のHDDをこの手を使って、データのチェックをしたり、内容消去を
したが、チェックに使ったLinuxマシンは一度も再起動せずにすんだ。
なお、ZFSには一応スペアディスクの機能があり、障害時にはこれに切り替わる
はずなんだが、うまく動かなかったので、単純なRAIDZ1にして使っていた。
その時のバージョンはrc8で、昨年の5月の連休にテストしたから、
今のバージョンでは動くかもしれない。
776:login:Penguin
13/02/04 16:54:56.01 vfNYlBcm
>>774
冗長性を持たせた vdev (mirror, raidz, raidz2) を使えば大丈夫だよ。
箱は↓このへんがおすすめ。
URLﾘﾝｸ(www.supermicro.com.tw)
LSISAS2008 や LSISAS2308 が乗った HBA を使えば、sas2iciru で故障したドライブの
LED を光らせたりとかもできる。
777:login:Penguin
13/02/04 17:27:46.31 MdIqgtlM
2012の記憶域プール/記憶域スペースは、zfsで言うなら、zvolを切り出すときにzvol単位で冗長性を指定できる感じだと思ってる
zfsではプール(を構成するメンバ)単位での指定だから、2012の方が柔軟なのかも
冗長性不要のものも混ぜられるから
778:login:Penguin
13/02/04 17:30:03.48 ggbXULcg
>>775
＞SATAのコネクタはOSが起動中に抜き差しが出来るみたい
それはシステムによる
コントローラ、電源、OS全部対応して初めて使える
779:login:Penguin
13/02/04 21:46:31.56 w3v5aG/Y
>>778
なるほど、前に試した時には認識しなかったり、
Linuxがカーネルパニックになったりしたけど、年末に
試したシステムは、マザーボードが新しいヤツなので
オンライン交換に対応してたのか。
780:login:Penguin
13/02/05 01:48:55.59 2nfprAI4
>>774
今のLVMってthin provisioningやraid 1/4/5/6が統合されたんだけど誰も使わないからノウハウが広まらなくて誰も使わないスパイラル
781:login:Penguin
13/02/05 01:57:44.33 pEXCZ1DL
>>780
その辺、fsまで統合しないといまいち気持ちよくならないしなぁ。
782:login:Penguin
13/02/05 16:19:01.78 8jmt/8C7
すみません、最近RAID1の機能を内蔵した外付けハードディスクがありますが、
こういうの↓って、Linux で使えるんでしょうか？
URLﾘﾝｸ(www.iodata.jp)
783:login:Penguin
13/02/05 16:40:25.35 1zAw6hnU
>>782
くだらねえ質問はここに書き込め！ Part 204
ｽﾚﾘﾝｸ(linux板)