19/02/01 08:04:15.23 N0xuylqN.net
>>345
Windowsはケースセンシティブじゃないから…
351:login:Penguin
19/02/05 23:09:56.64 KE7i+wC/.net
ext4で大文字小文字の区別をしないモードが開発されているらしい
352:login:Penguin
19/02/06 20:07:35.87 wB6R+SSI.net
それはそれでまた阿鼻叫喚の予感が…
353:login:Penguin
19/02/08 19:16:10.92 JCux+jot.net
ケースセンシティブでなきゃ死ぬ環境にも問題がありそうな気がする
354:login:Penguin
19/02/08 22:49:20.26 gM5IfNf+.net
昔、別の板でだけど
FAT32の外付けディスクにWin2000で大文字小文字だけの違うファイルを作って
それをWin98で読んだらどうなるかってのの話題があったな
FATの特性(エントリべた書き)もあるだろうけど
dirで表示されるファイルとエディタで開くファイルが違うとか、
移動させようとすると別な方が移動されるけど残った方が読めるようになるとか
いろいろ挙動不審だったら
355:しい
356:login:Penguin
19/02/15 13:03:48.45 4tPOtJVd.net
>>345
FS側じゃなくてsambaのname manglingじゃねえの
Windowsで使えない文字とかもSamba経由だとそうなる
357:login:Penguin
19/03/06 12:57:44.81 GYShYGFU.net
釈放されたんだから早くreiser4復活しろよ
358:login:Penguin
19/03/07 02:54:37.96 6s6dEvVm.net
ようやく時代がreiser4に追いつくか？
359:login:Penguin
19/03/07 09:33:29.95 MuV+t1Gm.net
今はbcachefsのほうが期待されてるだろう
360:login:Penguin
19/03/11 00:35:21.09 UOCKT9C0.net
md-raid 6上の6TBのbtrfsボリュームが怪しくなった
> BTRFS error (device sdb): parent transid verify failed on 222893 34353920 wanted 631557 found 632032
そして消せないサブボリュームがある
# ls -l /mnt/BtrfsTank
ls: /mnt/BtrfsTank/encoding にアクセスできません: 入力/出力エラーです
合計 0
drwxrwsr-x. 1 root video 636 3月 10 13:13 datastorage
d?????????? ? ? ? ? ? encoding
この?の並びが激しく気持ち悪くて不気味だ、このencoding内のデータはどうでもいいってか何も入ってなかった気がする
今の所読めないデータはないし読み書き含め他の部分は問題なく動いて見えるが、btrfs-select-superやbtrfs check --repairやってもダメなので
データ退避してから作り直すしかない
スナップショット撮っては消ししまくりにしてはよく頑張ってくれたと思う
データ退避処理の進捗をみながらRedHatがbtrfs投げ捨ててからの動きとか見てるけど
btrfs on md-raidでいいのかZFS on Linuxに移行すべきかなかなか良いスタンダードが確立してないよねぇ
361:login:Penguin
19/03/11 00:40:43.65 IigLLh3C.net
btrfsはトラブるたんびにモグラ叩き、の繰り返しだったろうに何故に実運用しようとするのか
362:login:Penguin
19/03/11 00:52:12.93 5TJmB3dg.net
video encodingかw
エンコ厨のアニヲタは氏ねばいいよw
363:login:Penguin
19/03/11 03:25:35.52 Iugc1R92.net
btrfsは失敗だもう捨てろ
364:login:Penguin
19/03/11 03:39:15.17 obZ/zwS+.net
btrfsのスナップショットは作る分にはいいけど…
365:login:Penguin
19/03/11 10:13:10.16 nc+22c0z.net
もうNILFS2は誰も見てくれないのかなあ。
結構好きで/homeに使っているのだけれど。。。
366:login:Penguin
19/03/11 23:14:39.58 SU9pN+Q4.net
どんなメリットがあって使っているの
367:login:Penguin
19/03/12 20:49:05.55 yL9gOqQR.net
>361
Logファイルシステムなんでファイル操作ごとにチェックポイントができるから保存されている限り任意の時点のファイルシステムの状態が復元できるんで、
あ、消しちゃったとか、間違えて書き換えちゃった時にすぐ取り返せる。
ルートで対象のチェックポイントをスナップショットに変更してマウントする作業する必要があるけど。。。
ファイルシステム止めずにスナップショットが得られるので他の作業しながらコンシステンシー気にせずにバックアップが取れる。
書き込み量とストレージのサイズによるけどデフォで1時間で設定で24時間位は遡れるようにしているので割と気軽にファイル操作している。
とは言っても実際にファイル取り返さないといけないケースは1年に数回程度だけど。
368:login:Penguin
19/03/16 17:38:18.22 RacPXVIy.net
このディスクのファイルシステム何かわかる人いませんか・・・・・・FreeBSDのUFSではマウントできず・・・・・・。
GPT fdisk (gdisk) version 0.8.10
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sdf: 3907029168 sectors, 1.8 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 5D5F6FE4-4185-11E4-AE7C-20C6EB48C57A
Partition table holds up to 128 entries
First usable sector is 88, last usable sector is 3907029134
Partitions will be aligned on 8-sector boundaries
Total free space is 5071 sectors (2.5 MiB)
Number Start (sector) End (sector) Size Code Name
1 88 4194391 2.0 GiB FFFF
2 4194392 3907011775 1.8 TiB FFFF
3 3907011776 3907024063 6.0 MiB FFFF
パーテション１をddで吸い出してfileしてみたら↓
# file backup-disk-image-sdf1.img
backup-disk-image-sdf1.img: Unix Fast File system [v2] (big-endian) last mounted on /tmp/mnt/ustorage3,
last written at Mon Mar 11 10:13:02 2019, clean flag 0, readonly flag 0, number of blocks 524288, number of data blocks 520071, number of cylinder groups 4,
block size 32768, fragment size 4096, average file size 16384, average number of files in dir 64, pending blocks to free 0, pending inodes to free 0,
system-wide uuid 0, minimum percentage of free blocks 8, TIME optimization
369:363
19/03/16 17:50:40.75 RacPXVIy.net
あ、ディスク自体はパナのVIERAに外付けHDDとして接続してたTV録画HDDです。
HDD自体はsmartやら、ddやらの読出し結果からは異常はないっぽくて、
どうも中のファイルシステムがおかしくなってるっぽいなんとか復旧したく。
各パーテション、CodeがFFFFでファイルシステムが何かわかりません。
fileの結果からは、/tmp/mntとなってるので、UNIX系の何かだとは思うんですが・・・・
370:login:Penguin
19/03/16 18:42:10.51 QAw47Obs.net
レコーダで初期化したHDDは独自のファイルシステムになってるもんじゃないの？
そうでないと録画データの引っこ抜きとかが容易になるわけで。
371:login:Penguin
19/03/16 19:11:00.46 FKDx4ojb.net
> Unix Fast File system [v2] (big-endian)
これが「UFS2」にしか見えなくて、
まずこれをやって
URLﾘﾝｸ(www.google.com)
次にこれをやってみて
URLﾘﾝｸ(www.google.com)
なんとなく
>>365
そんなことしてたら、コストに見合わない
安定性やバグ取りにサポートまで必要なことに手を出すほど、メーカーはヒマじゃない
せいぜい多少の細工をして外部から読みにくくすることがあるかも程度
372:363
19/03/16 21:15:49.38 RacPXVIy.net
ありがとうございます。独自ファイルシステムだとコスト的にあわなさそうというのは同意見です。
TV側のOSkernelレベルからカスタムする必要がありそうですし。
吸い出したddをもとに、現状、以下をやってます。
・別HDDへのｄｄでの丸コピでどうにかならないか
→ HDD個体識別はGUIDでやってるだろうという推測ベースで激遅コピー中。HDD異常ではなさそうなので�
373:]み薄。 ・ddとったイメージをいろんなOSでマウントして中身をみてみる → USF2対応のFreeBSDでマウントしてみたけど、なぜかデバイスファイルのリンクがきれててNG。 GUIDとか、gpt上のファイルシステム№、ラベルとかを振りなおしてもだめでした。 ddイメージのfileの結果はUSF2だけど、gptのcode上はUSF2を示すA503ではなく、 FFFFで、リザーブ№というか、末番なのが果てしなく怪しい。 ・マウントせずにファイルを見れるツールを使ってファイルだけ吸い出してみる → 大量の分割ファイル（mp3、mlv？）。あとSQliteとかいうDBMS関連と思われるファイル（dbx、sqlite、txt） 某社みたいにmpegファイルとして直で保存してなくて、DBMS内に格納していそうな予感。 DB論理破壊なら絶望的・・・・・。そもそも構造もよくわからんし・・・・。 現状からすると、UNIX系をベースにファイルシステム、保存方法の両方に細工がされてそうに見えます。 DB解析はあきらめて、ちょっとファイルシステムが壊れてるだけです！の方向で継続してま・・・・・ 東芝のTVにしとけばよかったなぁ・・・・
374:363
19/03/16 22:17:05.43 RacPXVIy.net
てきとうにやってたら━(ﾟ∀ﾟ)━DB構造見えてきたー
URLﾘﾝｸ(imgur.com)
このDBはプリセットっぽいけど一応データを見ておこう・・・・・・
？？？？TVよりはるか昔のなにやら不穏な文字列がががが・・・・・・
パナに怒られても嫌なのであれなところは黒塗りで・・・・・・・・
URLﾘﾝｸ(imgur.com)
ということで全力でDBデータ吸い出し中。
375:login:Penguin
19/03/16 22:54:00.06 RacPXVIy.net
TV録画HDDまるごとddイメージ用の2TB、
TV録画HDDのパーテションごとddイメージ2用のTB、
パーテションごとddイメージの一応swabイメージ用の2TB、
DB吸い出し用の2TB。空き容量ガー。
今日はもうddでHDDコピーしながらDB吸い出し仕掛けて寝ることにしま・・・・
もし同じような境遇でデータ救えた人がいればアドバイスいただきたく・・・
376:login:Penguin
19/03/18 19:49:09.41 Vfq3Yari.net
デコードできるのそれ？
377:login:Penguin
19/03/18 20:09:35.84 23E+fOK/.net
録画データ壊れてて読み込んだ時点で死んでるとかじゃなければDB修復したら元のTVで見れるでしょ
378:login:Penguin
19/03/18 21:24:29.74 Vfq3Yari.net
あ、そゆことね
379:363
19/03/21 01:42:47.79 /l10lWhU.net
はい。結局マウントかけずにフアイルを読み出すツールだと、情報が断片的にしか読めずDB復旧にはいたりませんでした！あと、ddの完コピディスクも予定通りダメなとこまでコピーされてだめ！南無！
380:363
19/03/21 01:45:46.80 /l10lWhU.net
結局、gpartのFFFFコードの小細工を突破して、正攻法でマウントして読み込んでffckなりするしかなさそうですが、これはうちのスキルではむりんご。
381:login:Penguin
19/04/09 13:17:11.49 1OOoyLh/.net
【速報】削除後、起動しているだけでデータが復元できなくなるという性質がLinuxのファイルシステムに存在することが判明
URLﾘﾝｸ(cloud.watch.impress.co.jp)
>Windowsでは、1回削除してもファイルシステム上にはフォルダ構成が残っているのですが、
>Linuxに関しては、削除後はしばらくそのままにしているだけでどんどん消えていきます。
>起動しているだけでデータが消えるという性質がLinuxのファイルシステムにはあります。
382:login:Penguin
19/04/09 13:22:56.97 lhCkt0bg.net
ファイルシステム名すら書かずに
383:login:Penguin
19/04/09 13:39:29.81 izrDON32.net
セキュリティ的にはそのほうがいいんじゃない？
384:login:Penguin
19/04/09 13:41:03.99 xKrw21om.net
>>375
Linuxでは削除したデータの復活が難しいって話でしょ?
データが勝手に消えるという意味ではないぞ
385:login:Penguin
19/04/09 14:45:23.63 MWJmYr9/.net
ファイルシステムの仕様の話でバグでもなんでもないよな
それにファイルシステム上から完全に削除したファイルの復元なんてWindowsにしろLinuxにしろ保証なんてしてないし
386:login:Penguin
19/04/10 11:00:23.00 4T4hCHHJ.net
ext4との比較かな
そんな性質あるのか？ssdの場合か？
387:login:Penguin
19/04/10 11:51:08.21 sqoFbBjM.net
ext4は結構戻せるからxfsのことでないかな
388:login:Penguin
19/04/11 07:56:59.03 4Cyx3VjH.net
>>377
一般的には、そうだよね。
記事の内容は、視点がフツーじゃない。
389:sage
19/05/02 07:41:59.61 uuWYZZoh.net
>> 363
LGのTVの録画に使っていたディスクが壊れて調べたらLGのモデルでは次のようなことがあるらしい。
URLﾘﾝｸ(www.avforums.com)
ひとことでいうと、録画ファイルのメインデータは JFSの第一パーティション。
メタデータ（リストとかかな？） はext3の第二パーティションに書き込む。
パーティションタイプはa2という独自のものを利用している（！）
新しいディスクはLG TVにフォーマットさせてたが、
TVが初期化した以前の２TBのWDディスクは
fdisk -l でみるとパーティションのバウンダリがセクターの始まりにないという。
そこでlinux の上で gparted で jfsのパーティションと最後に５０MBほどのext3のパーティションを
つくり、そのあとfdiskの t コマンドで パーティションタイプをa2 に書き換えて、
上のAVForumの投稿にあるように無事つなげた。
（最初まちがってa1を書き込んだらUSB機器に問題があるといって認識せず。
正しくa2にしたら接続したが、「初期化」しますかと聞いてきた。
パーティションから作りかえることはしないだろうとOKして使えるようになった。）
古いディスクは ddrescueで読みだそうとしているが、3日かかるとか出ていてあきらめ状況。
小さいext3部分は強制的にext3としてマウントできた。jfsの方はだめだった。
消費者としては録画ハードディスクをつなげることができるTVでは
- S.M.A.R.T.の情報を表示して欲しい（ディスクが壊れる場合の８０％くらいはS.M.A.R.T.で予測できるのではないかな。
あとの２０％はいきなりこわれるから、気休めだが。）、
- Windowsマシンなどでバックアップコピーを簡単にできる方法を提供してほしい
とつくづく思った。
（TVの内部キーで暗号化している部分があると思うので、他では再生できないバックアップなんだけども。）
メーカーが独自ファイルシステムなんて作る余裕はないという考えには同意。
LGはパーティションタイプを変えることで obfuscateしているんだけども上記のAVFORUMの投稿者はどうやって知ったんだろう？
390:login:Penguin
19/05/03 02:19:19.70 MTUS+yEB.net
ファイルのヘッダ見るだけでファイルタイプがわかるように、
その人もパーティションのヘッダを見てファイルシステムがわかるんしゃないかな。
ファイルシステムにシグネチャとかあるのか知らんけど。
391:login:Penguin
19/05/03 12:16:35.70 Wzb7upON.net
無かったら mount -t auto なんて出来ないぞ
392:login:Penguin
19/06/05 11:45:36.91 7o3gJPQx.net
NixOS Takes Action After 1.2GB/s ZFS Encryption Speed Drops To 200MB/s With Linux 5.0+
URLﾘﾝｸ(www.phoronix.com)
ZoLもうダメそうだな
393:login:Penguin
19/06/05 14:08:52.34 rn1dV4UN.net
AES-NIが使えなくなってそこまで遅くなってるんだろう
暗号化をAESからchacha20に切り替えたらかなり改善されると思う
394:login:Penguin
19/06/05 16:08:58.99 ODK3wUcN.net
>>386
あらら(´・ω・｀)
395:login:Penguin
19/06/13 01:37:16.29 vP00iu9C.net
>>387
ChaChaもChaChaでSSE/AVX使えないのはつらいぞ
396:login:Penguin
19/06/16 06:51:50.05 fORVbt/P.net
ARXはあまりアーキテクチャ依存しないから速いよ
397:login:Penguin
19/06/26 02:22:44.66 wL+APPob.net
改心したはずのトーバルズ氏がまたもや感情的な暴言
Liam Tung （Special to ZDNet.com） 翻訳校正： 編集部 2019年06月25日 12時28分
URLﾘﾝｸ(japan.zdnet.com)
(前略) Torvalds氏に早速かんしゃくの矛先を向けられたのは、オーストラリア人プロ
グラマーのDave Chinner氏である。Chinner氏は、多くのLinuxディストリビューションが
サポートしているSilicon Graphics製のXFSファイルシステムを管理している。(中略)
しかしTorvalds氏は、Chinner氏の言い分を否定し、そのような考えを広めようと
している開発者は「無能だ」と痛烈に批判した。
「Dave、キャッシュはちゃんと機能する。そう思わない者は無能なだけだ。ファイル
システムによるアクセスの99％はキャッシュに保存され、IOを行うことは決してない。
ページキャッシュはファイルシステムを美しく処理している」（Torvalds氏）
それに対してChinner氏は、Linuxの行動規範に従い「礼儀正しく議論する」ことをリマイ
ンドし、カーネル開発者がプロらしく論議できる雰囲気を作ろうと、次のように回答した。
「その通りだ。ページキャッシュは多くのストレージより高速なため、問題なく機能する
ケースはたくさんある。しかし、私が指摘したのは、そのことではない」「わたしが、IOの
並行処理、ページキャッシュ、既存コードのアーキテクチャー上の不具合などについて書い
た長文のメールの中から、たった1つの記述を前後関係を無視して引用し、まったく新しい
文脈をでっちあげた上で、私がキャッシュやページキャッシュのことを全く理解していない
と非難し始めた。」「プロらしからぬ振る舞いだ。しかし残念ながら、まったく予測できた
反応だとしか言いようがない」とChinner氏は応じている。
398:login:Penguin
19/06/26 15:14:51.68 6o+Ir3lv.net
>>391
>ページキャッシュはいまも、ダイレクトIOよりかなりスピードが遅い。そしてNVMeのSSDが高速になればなるほど、
>そのギャップは広くなりつつある。PCIe 4のSSDで、この問題はますます明白になるだろう。もはやページキャッシュを
>使用する理由は、旧態依然としたディスクストレージを使う手頃な価格のシステムやmmap() をサポートするためだけになりつつある
じゃあnvme用に新しいファイルシステム考えれば良いんじゃね？って気はするけどね。
磁気ディスクを前提としたファイルシステムIOいじって喧嘩するなよｗｗ
399:login:Penguin
19/06/26 21:25:29.86 LXNNeckR.net
何言ってんだ
ページキャッシュはファイルシステムの機能ではないだろ
400:login:Penguin
19/06/26 22:04:26.08 08MS9y/0.net
SSD向けのファイルシステムならもうあるからな
401:login:Penguin
19/06/26 22:48:54.02 6o+Ir3lv.net
>>393
> ページキャッシュはファイルシステムの機能ではないだろ
ではないにしても最終的にこの人が弄ったのはfs/配下なんでしょ？
何れにしてもそんなコアな部分を、nvmeの為に変更しますとか言ったら
揉めるのはしょうがない。
402:login:Penguin
19/06/26 23:23:02.57 OjXYcy1P.net
どちらかというと仮想メモリ周辺の話じゃないか
403:login:Penguin
19/06/26 23:31:21.49 6o+Ir3lv.net
何にしても特定機能の為に汎用部分弄ったら怒られるのはしょうがない。
404:login:Penguin
19/06/27 07:53:35.03 1kwJgDpi.net
非常に根本的が疑問があるんだが
ダイレクトI/Oより遅いページキャッシュってなんか話がおかしくね
ページキャッシュってオンメモリならストレージインターフェースより速いはずでは…？
405:login:Penguin
19/06/27 10:34:39.89 j+m7QE0N.net
ページキャッシュが無い環境を使ったことがないから分からんな
どうなんだろうな
406:login:Penguin
19/06/27 13:32:07.45 Va09TTiq.net
>>398
オンメモリでもページキャッシュの管理コストが絶対に発生するので
昔はストレージアクセスが文字通り桁違いに遅かったので管理コストは
無視しても差し支え無かったけど今はそうも言ってられなくなったってことかと
407:login:Penguin
19/06/27 21:45:22.84 icJgPc2A.net
ダイレクトIOが遅いって言ってるのは
rawデバイスでDB扱うレベルの話でOK?
でないとRAMがSSDに。ページキャッシュのコストがあるとはいえ遅いという話にはならんと思うんだが
408:login:Penguin
19/06/27 22:50:29.23 LI96p1HW.net
NVMeも通り越して、3DXpointだかあの辺のDRAMの数分の1くらいまで速いメモリを使うようになったら
ページキャッシュ経由するより直で読み書きした方が良くね？って話ならまだわかるけど
いくらNVMeでもフラッシュメモリ使っててページキャッシュはオーバーヘッドだからもう要らないみたいな話なら、何言ってんだお前…ってなる
409:login:Penguin
19/06/28 17:51:59.02 b8zcOuzC.net
jfs使てる人おらんの
410:sage
19/06/28 18:01:49.33 1jOqGt+U.net
>> 391
これって、次見るとわかるけど
URLﾘﾝｸ(lkml.org)
要は、一般的な場合ではなくて、非常に大きくて（しかもアクセスパターン考えると）キャッシュになじまない
ような大きなデータのときにはページキャッシュのオーバーヘッド大きい、また（そのような場合には）
キャッシュに使うようなLRUみたいな汎用なアルゴリズムでなくてアプリケーションの方が素性が分かっているからそっちにキャッシュさせろと。
いうごく当たり前のこと言っている。しかも発言者は数字はだしてないが、多分９５％くらいのアプリケーションは
全然いまのページキャッシュでも問題ないということも言っている。
つまり のこりの数値は私の感覚だが５％の大きなデータセットを使うDB（たとえばOracle)、big data crunchingとか
の場合を話をしているわけで、どこを見るかですれ違いは無理もないかもしれないがなんだかな。
ページキャッシュの話を読んでて、次の話を思い出した。昔Sun Sparc V6だったか、bitblt 命令が入って、
白黒画面程度だったらCPUだけで簡単なウィンドウサポートができるようになった。
ただし、、MC６８Kなんかの場合にCPUだけでやって困ったのが、カラー画面の書き換えしただけで
キャッシュが使われてしまって肝心のユーザアプリケーションのデータがキャッシュから追い出されることがある。
つまりカラー画面のデータって結構大きいので、そこを書き換えるとアプリケーションのデータがキャッシュから
おいだされてしまうことがままある。
Sun Sparcの場合には、bitblt関係の命令っで使ったデータはキャッシュしないことで
この問題を解決して、なるほどと思った。
巨大なデータセットがページキャッシュをバイパスするのも同じような話なんだけども、
なんでLinusは理性ある対話ができないのだろう？
411:login:Penguin
19/06/28 20:21:42.62 GazpYCiw.net
対話をする気がないか、諦めてるんじゃないの？
412:login:Penguin
19/06/28 20:40:28.14 WA1on6xu.net
流れを見てないからわからんけど
これだけ見ると老害化してるやん
413:login:Penguin
19/06/28 21:03:39.64 KMXUlWzl.net
最近の書込みキャッシュ付きの RAID コントローラだと、NVMe/SSD に対しては
キャッシュを通さず直接書き込むほうが早いからそうしているらしい。
ちまちま4KBずつどのキャッシュを抹消していいかを計算しながらの、
ページテーブル書き換えながらの、だと本当に遅いんじゃないかね。
414:login:Penguin
19/06/28 21:47:13.92 UfcHNutv.net
消去がボトルネックというなら納得かな
415:login:Penguin
19/06/29 00:02:34.09 aGo2YBvo.net
RAID-Zのオーバーヘッドが今一つ分からないわ…。
パリティ+1の倍数分のブロック単位で区切るから、無駄が出る事が有るよって事？
スプレッドシートの数式見てもピンと来ないぞ…。
block size in sectors …、in sector ってどゆこと？単純に使用するブロックの数？
URLﾘﾝｸ(www.delphix.com)
416:login:Penguin
19/06/29 11:34:54.48 55acDkj4.net
>>409
block size in sectors はファイルシステム側のブロックサイズ(またはデータベースのブロックサイズ)で、
OSがファイルシステムに対して書き込むを要求する基本サイズだね。
in sectors は KB 単位じゃなくてセクタ単位で書きましたよ、この書き方ならブロックサイズ 512B の人も
4KB の人も同じ表で良いよね、ってだけじゃないかと。
417:login:Penguin
19/06/29 11:46:31.18 55acDkj4.net
以下チラ裏。個人的解釈。
シートの Example にあるディスク７本のRAID-Z1を考える。
ブロックサイズ(プログラムやデータベースからの１度の書き込み要求のサイズ)が大きい場合は、
ディスク本数７－パリティ数(RAID-Z"1")＝６なので、基本６セクタごとにパリティ１セクタが付与される。
RAID-5 と違ってブロックサイズが６セクタ未満の場合はパリティが１セクタ付与されるだけ。
例えば３セクタならパリティ１個追加して４セクタ分書き込む。
RAID-5 なら６セクタ＋パリティ１個の７セクタ単位でしか書けない。
ただしRAID-Znは n+1 セクタ単位で書き込む必要があり、条件を満たさない場合は足りないセクタ分
パディングされる。 RAID-Z1 は n=1 なので書き込みセクタ数は２の倍数でなければならない。
なので２セクタ書き込む場合は、パリティ足して３セクタではなく４セクタ。
Example に戻って１度の書き込みのセクタ数が１６の場合、
セクタ1-6+パリティ + セクタ7-12+パリティ + セクタ13-16+パリティ
の計19セクタ、n+1の倍数の制限でパディングが１セクタ追加されて総計20セクタ必要。
パリティとパディングは 20-16 で 4 セクタ。
データに対するパリティとパディングの比率は 4/16 で 25% になる。
418:409
19/06/30 00:08:50.88 Iwm+1v/G.net
>>410-411
おお、ありがとう。データとの比率だったのね。スッキリしてきたよ。
最近ZFSについて調べ始めたのだが、いろいろと難しい…。
分かっていない所だらけなんだが、
・>>in sectors は KB 単位じゃなくてセクタ単位で書きましたよ → 使用されたブロックの数という認識で良い？
・ブロックと表現されているものは、NTFSで言うクラスタみたいなもん
・ブロックサイズは、4、8、16、32、64、128KBで可変（DBの人は8KBをセットする？）
・書き込まれるファイルのサイズによって、ブロックサイズとブロック数が変わってくる
という事であってますか？
419:login:Penguin
19/06/30 03:37:15.39 QfL+H/59.net
>>412
俺も ZFS についてはど素人なので下記内容については
420:詳しい人による査読希望。 参照先の文脈においては、 (スプレッドシートの縦軸における)ブロック → 一回の書き込み量であってLinuxのファイルシステムのブロックサイズではない。 セクタ → ディスクに書き込む際の最小単位。 参照ページの２番目の図の P0 とか D0 の箱１個分。 セクタブロック → セクタと同義と解釈。 フィジカルブロックサイズ → セクタサイズと解釈。 (私見ではLinuxのファイルシステムの場合だと基本ブロック＝セクタ＝4KBなので厳密にどっちの話をしているか曖昧) だと解釈。 > ・>>in sectors は KB 単位じゃなくてセクタ単位で書きましたよ → 使用されたブロックの数という認識で良い？ 使用されたフィジカルブロック数という認識ですね。 > ・ブロックと表現されているものは、NTFSで言うクラスタみたいなもん Linux スレ的にはそう。 フィジカルブロックならそう。 スプレッドシートの文脈のブロックなら違う。 > ・ブロックサイズは、4、8、16、32、64、128KBで可変（DBの人は8KBをセットする？） フィジカルブロックサイズは固定。 > ・書き込まれるファイルのサイズによって、ブロックサイズとブロック数が変わってくる フィジカルブロックサイズは固定でブロック数だけ変わる。 zfs で動的ストライプ幅って言ってるのはフィジカルブロックサイズ(RAID装置によってはチャンクサイズって呼んでる部分) が動的に変化するのではなく、パリティグループ(データ＋パリティ,2番目の図の色が同じ箱のセット)の幅が動的ってだけ。
421:login:Penguin
19/07/02 01:12:51.76 15r1RiO6.net
>>413
うーん…、頭がこんがらがってきた。
URLﾘﾝｸ(docs.oracle.com)
「ブロックサイズが自動的に調整されます」というのは、何を指示している…？
422:login:Penguin
19/07/02 02:26:53.70 vY+H/LKm.net
URLﾘﾝｸ(i.stack.imgur.com)
URLﾘﾝｸ(i.stack.imgur.com)
URLﾘﾝｸ(genomewiki.ucsc.edu)
URLﾘﾝｸ(genomewiki.ucsc.edu)
URLﾘﾝｸ(genomewiki.ucsc.edu)
やはりext4が攻守最強か
423:login:Penguin
19/07/02 02:32:52.56 VNdE/qGn.net
パフォーマンスとかコストとかならそうなんだろうけど、
透過圧縮とか正当性の検証とかとなるとzfsのが上ってかext4じゃ無理
424:login:Penguin
19/07/02 05:18:02.15 FKCbYBRA.net
xfsは重複排除とCoWに逆マッピングも対応したのは聞いてたけど
フォーマットの段階でオプション有効化する必要があったのか
今使ってるxfsとは全く別物だなこりゃ
URLﾘﾝｸ(strugglers.net)
425:login:Penguin
19/07/02 07:23:04.59 dV8XE8AH.net
鯖屋は大変だな
俺みたいな一般人は黙ってext4使ってりゃいいんだろ？
現状はそれで過不足ないし臨機応変に使うFSを吟味しろとかやってられん
426:409
19/07/02 07:59:51.04 7tOiBm/F.net
>>414
> > ・ブロックサイズは、4、8、16、32、64、128KBで可変（DBの人は8KBをセットする？）
> フィジカルブロックサイズは固定。
この文書からするとここが間違い(フィジカルブロックサイズは固定ではない)ですね。
元の文書でデータベース向けに 6KB に調整したってのがあるがそれがこれってことでしょう。
ソースを弄って調整した可能性もあったし、サイズが可変は間違いという話もあったので固定だと思っていました。
427:login:Penguin
19/07/02 08:18:06.21 7tOiBm/F.net
>>418
企業向けの大きいストレージは保守がハードとミドルウェアでセットになってないとNG。
加えて10年ぐらい前に luster や gluster fs, zfs ベースの製品が雨後の筍のように出てきたけど皆失敗した。
現状信頼されてるのは Isilon (OneFS) で、その下に NetApp (WAFL)。
HPE の 3PAR (AdaptiveFS?しらん) も評判下げずに続けてるようだ。 IBM の gpfs 使う製品もある。
言えるのは全てプロプラエタリで、オープンソース・フリーソフトの製品は企業は怖くて使ってられないみたいね。
なので鯖屋もストレージ屋に丸投げするしか仕事がないんじゃないかな。
428:login:Penguin
19/07/02 18:13:16.85 vY+H/LKm.net
オープンソースは
企業がバックにいないと話にならないよね
そういう意味ではRedHatが公式に支えているxfsがベスト
429:login:Penguin
19/07/02 20:23:04.94 RJ/Pz5R6.net
企業に支えられていないファイルシステムってどれのことだ？
430:login:Penguin
19/07/02 20:45:36.79 CdZ1Kw09.net
プロプラ由来かOSS由来か…って事なんじゃね
431:login:Penguin
19/07/02 21:28:31.67 rRMzFXGI.net
Reiserfs
出所したから復活するってのは嘘だったのかな
432:login:Penguin
19/07/02 22:16:53.32 9meA9UgT.net
ｽﾚﾘﾝｸ(linux板)
↑ここから誘導されてきたファイルシステム素人なんですけど
ext4が十分ではない場合って例えばどんな場合がありますか。
そしてext4では十分ではない場合にxfsやbtrfsを使えばその問題を解消できるんですかね。
ext4が対応できない問題って大抵のファイルシステムが対応できなさそうに思うんですけど……。
433:login:Penguin
19/07/02 22:24:04.87 +bA9GvGw.net
個人利用なら今でもreiserfs有用だと思う
あの早さが必要で諸々理解して使うなら
reiser4fsの開発開始しないかなしないだろうな
>>425
ext4遅い
ext3よりreiserfsの方が倍くらい早いんじゃないか？という感動は忘れられん
434:login:Penguin
19/07/03 00:05:11.18 NZGhw/Gn.net
>>426
速度の問題があるんですね。
意識したことなかったです……。
バカな質問に答えてくださいありがとうございます。
435:login:Penguin
19/07/03 00:53:08.95 Qt/N9GEP.net
今時パフォーマンスを最優先にするならF2FSでしょう
reiserfsはもう相対的にそこまで早くもないし
URLﾘﾝｸ(www.phoronix.com)
436:login:Penguin
19/07/03 01:20:53.54 ZZuB/vaR.net
そして障害時の対応で時間を食うと
437:login:Penguin
19/07/03 01:22:02.01 V5c8y5zy.net
>>425
>ｽﾚﾘﾝｸ(linux板)
こういう人って zfs も LVM に乗せて LV リサイズしたら壊れたって騒ぐんだろうな
438:login:Penguin
19/07/03 01:44:17.52 E6xhFUOk.net
用途にも寄るしな
安定性が課題のFSはテストならまだしも実用は怖い
個人デスクトップ用途だと小さめのファイル扱いはSSDだとそれほど差を感じないだろうが
大きなサイズの扱いはSSDでも時間かかる、これが早くなると体感がかなり違う
とするとReiserFSは安定してるし、デスクトップ用途かなり良さそう
439:login:Penguin
19/07/03 03:41:45.20 v76vN8mT.net
そんな終わったFSを前提にされても
440:login:Penguin
19/07/03 11:23:23.07 lvGvaRtu.net
>>425
うちは透過圧縮が欲しいから/をbtrfsにしてる奴がある(ZFSはツリー外のモジュールとか面倒くさいしfuseも使いたくない)
早いCPU+遅いHDDの組み合わせでディスクアクセスがボトルネックになってるような環境だと結構目に見えて高速化されるよ
ぼんやりとしか使ってないってのもあるけど3年ぐらい使ってて特にトラブルは無いな、まあデータを置こうとは思わんけど
つかswapファイルに対応したりとか普通に開発継続してんのにRedHatが抜けたってだけで放置とか色々言ってるやつはアレやな
441:login:Penguin
19/07/03 12:13:29.85 Y5ON4Ylq.net
だってRed HatのAndy Grover様も
Btrfsはメーリングリストが断末魔で埋め尽くされていてクソって言ってるんだもん
URLﾘﾝｸ(strugglers.net)
442:login:Penguin
19/07/03 16:06:18.82 IxUC1S3v.net
btrfsは互換性とか影響範囲とか考えずにどっかで再設計すれば違う展望もあっただろうになあｌ
443:login:Penguin
19/07/03 20:49:55.88 pn6xgYzw.net
断末魔と団地妻って似てるな
444:login:Penguin
19/07/04 08:58:47.97 MPcWxAgH.net
btrfsの後釜になれるかもしれないbcachefsがそろそろLinuxカーネルのメインラインに入るぞ
おそらく次かその次のバージョン
445:login:Penguin
19/07/04 09:09:45.05 5FppRmLC.net
メーリングリストが団地妻で埋め尽くされるとか股間が熱くなるな
ファイルシステムが乱立ってのもなんだかなぁ
zfsをパクって機能削減してxfsと足して２で割り切れない感じでいいと思うんだが
446:login:Penguin
19/07/04 09:13:41.09 t19oAjJ9.net
そういうお前も新しいの作ろうとしてんじゃん
447:login:Penguin
19/07/04 10:30:19.24 66v4UI/A.net
bcachefsのホームページ見たら
最初の一文からアレを意識しすぎぃぃぃ
＞We prioritize robustness and reliability over features and hype:
＞私達は機能と誇大宣伝よりも堅牢性と信頼性を優先します。
URLﾘﾝｸ(bcachefs.org)
448:login:Penguin
19/07/04 12:10:02.17 rpGqPEX9.net
究極たるzfsを崇めよ
449:login:Penguin
19/07/04 15:51:02.60 P64f5rak.net
>>440
先生！堅牢性と信頼性より機能と過大宣伝を優先したファイルシステムが多すぎてどれか特定できません！
450:login:Penguin
19/07/04 15:52:17.40 P64f5rak.net
しかも
URLﾘﾝｸ(mstdn.jp)
らしいし。
451:login:Penguin
19/07/04 16:54:53.24 +XLHt8Ha.net
>>443
そのベンチマークは1年前で古いこっちの最新の結果を見た方が良い
URLﾘﾝｸ(www.phoronix.com)
XFS安定という結果には変わりないけど
452:login:Penguin
19/07/04 17:09:39.55 6XXEq2Nj.net
bcachefsは新しいけどベースがbcacheだからすでに信頼性はそれなりにありそう
まだ使ったことないけど期待はしておく
453:login:Penguin
19/07/04 17:18:29.96 JEN2SxWZ.net
F2FSってフラッシュストレージ向けのくせに最近はHDDのサポートもしてきてるんだよな
HDDで使うことはないだろうけど
454:login:Penguin
19/07/04 19:12:45.96 rpGqPEX9.net
枯れてないFSなんて地雷やで
455:login:Penguin
19/07/04 19:29:25.21 1YidJb1m.net
そうは言ってもxfsも最近は新機能追加しまくりだし
枯れてるの定義は結構難しいぞ
456:login:Penguin
19/07/04 20:03:25.18 P64f5rak.net
MINIXファイルシステムを使おう！
457:login:Penguin
19/07/04 20:32:20.56 z0Pbt8nE.net
最強に安定しているのはntfs
なお
458:login:Penguin
19/07/04 20:53:14.61 zNLNx3om.net
>>437
始まったな
459:login:Penguin
19/07/04 22:44:03.98 N/xMrX9J.net
windowsで安定してマウントできるファイルシステムは今はどれなんだ？
ext4ですらなんか怪しい感じなんだよなぁ
460:login:Penguin
19/07/04 22:48:44.94 JEN2SxWZ.net
>>452
btrfs
461:login:Penguin
19/07/04 23:01:52.19 nCIQ4/jH.net
>>452
ext2fs+ext4
これでだめだったらwindows窓から投げ捨てろ
462:login:Penguin
19/07/05 00:04:02.89 tcFjwaW7.net
wsl2が来るまで待て
463:login:Penguin
19/07/05 00:10:18.86 j7UvDQ62.net
仮にntfsがオープンソースになってカーネルにマージされたら
互換性も考えてほぼ一択化になるだろうな
464:login:Penguin
19/07/05 00:23:35.79 G1guSEeh.net
>>454
ext2fsって開発が滞ってないか？
それに、環境によって、最新版だとマウントできないみたいだし。
実際自分のところもできなくて、いくつか戻す必要があった。
465:login:Penguin
19/07/05 00:51:32.72 w6qq3pqZ.net
ファイルシステムのシェアってどんなもんなんだろうな
デバイス数では地味にF2FSが上位かもしれない
466:login:Penguin
19/07/05 02:22:44.82 54nYef5x.net
NTFSそれ自体の評価って高いの？
それともNTFSの概念や
467:設計が評価できるの？
468:login:Penguin
19/07/05 02:40:31.93 7kZq9gYf.net
ディスクのハード故障を除けばNTFSで致命的な状態に陥った経験は無いな
469:login:Penguin
19/07/05 02:53:50.58 q3JGl+2T.net
>>459
NTFSは特に良いところもなく、ファイル破損が良く起きる経験しかない
470:login:Penguin
19/07/05 03:00:14.05 j7UvDQ62.net
全世界のPC初心者に有償で提供してるだけあって
少なくともWindows上ではクッソ安定してる
Winを使ってるような層を相手に安定してるんだから異次元としか言い様がない
471:login:Penguin
19/07/05 03:02:08.04 q3JGl+2T.net
いやそういうの要らないから
対立煽りってやつ？
472:login:Penguin
19/07/05 04:11:17.66 SYL5tGuC.net
安定していると言ったら対立煽りに見える思考やばいだろ
473:login:Penguin
19/07/05 05:35:22.47 f3vjr6Xw.net
>>454
上手い事言ったつもりかｗ
474:login:Penguin
19/07/05 06:48:52.45 54nYef5x.net
>>462
なるほど。そういう見方もあるな。
Unixは基本的にファイルシステムをある程度理解してるから
Windowsの大半の利用者みたいな使い方はしないわな。
その上で安定してるというのであればすごい。
でもそんなに安定してる？
475:login:Penguin
19/07/05 07:42:17.19 q3JGl+2T.net
ntfsは電源断などのファイル破損が起こりやすいところとか
度々ext系ほかと比べられてるけど、同じ話ループしすぎなような
476:login:Penguin
19/07/05 08:25:02.29 54nYef5x.net
どうでもいいけどWikipediaのBrtFSの記事すっごく宣伝調だね……
477:login:Penguin
19/07/05 10:14:55.89 lGHrYghR.net
>>459
URLﾘﾝｸ(togetter.com)
UbuntuJPの中の人曰く
478:login:Penguin
19/07/05 12:10:41.83 kGpLF8uq.net
＞「今のLinuxにNTFSレベルにマトモなファイルシステムなぞない」
まで読んだ
479:login:Penguin
19/07/05 12:25:54.82 yalE+Jvn.net
アンチMSには理解し難いだろうけど、エンドユーザーが利用可能でよくメンテされて機能的にNTFS以上のファイルシステムってちょっと思いつけない、あるなら例示して？…ってなるな。
ああ、「俺の好きなFS」じゃないんで。まあ言っても理解できないだろうが…
もちろんWindowsから扱う場合の話で、互換環境で同等の信頼性があるとは思えんが。
それでもUFSやextよりはずっとマシ
480:login:Penguin
19/07/05 12:26:03.28 8tR6yfC3.net
そういえばBSDのハマー2の評価はどうなの？
481:login:Penguin
19/07/05 12:28:53.02 yalE+Jvn.net
Linux環境だと、データセンター並みに巨大なボリュームを扱うとか、ウェアレベリングの無いフラッシュメモリをストレージにする組み込みみたいな特殊用途でない個人ユースなら、消去法でext4が無難か…
482:login:Penguin
19/07/05 12:30:53.10 yalE+Jvn.net
>>468
たまにあるよね、読者を説得というか、折伏？しようとしてる記事。
483:!ninja
19/07/05 12:40:54.45 rX9H6RAi.net
デスクトップとしてLinuxを使用して写真の現像とか色々しているけれど
ext4で問題になった事はないです。(安定しています)
因みにWindowsはカメラのファームアップとOSアップデート位しか使わない。
484:login:Penguin
19/07/05 14:25:39.16 qDrdSQQO.net
別に個人が普通に使うならどれでも滅多に困らない
485:login:Penguin
19/07/05 17:01:26.55 5Oj7dNKU.net
外付けHDDをLinuxで使う場合、
FAT32は無いものとして、
NTFSとexFAT、どちらのほうが無難？
486:login:Penguin
19/07/05 17:18:10.07 aHzpu2WI.net
外付けHDDだってことは、複数のOSからmountすることもあるだろうから
exFATが無難というか最良かと
487:login:Penguin
19/07/05 17:29:29.45 0uxDVNFV.net
>>472
Dragonf
488:lyBSD使てる日本人は居らん
489:login:Penguin
19/07/05 23:39:13.82 QVfQ7xAQ.net
COWありでまともに使えるファイルシステムはどれなんだー
490:login:Penguin
19/07/06 00:04:47.81 8LM9xkHS.net
xfsでしょそりゃ
ただしフォーマットし直さないとCoWは有効化出来ないけど
491:login:Penguin
19/07/06 04:51:15.15 g9aj4tWg.net
xfsのcowってまともに使えるのか？
最近使えるようになったばかりだろ
新しいファイルシステムと同じようなもの
492:login:Penguin
19/07/06 04:59:40.34 8LM9xkHS.net
xfsのメンテナが自分のPCで
CoW導入で使えるようになった
新機能の重複排除を使ってると言ってるのだから安心していいかと
493:login:Penguin
19/07/06 05:20:44.07 VaeT5YKG.net
そりゃファイルシステムのメンテナなら自分のPCで動かしてて当然だろうな
494:login:Penguin
19/07/06 05:27:27.89 L3XPzqxa.net
俺はbtrfsのメンテナがbtrfsを常用しているとは思えない
495:login:Penguin
19/07/06 05:32:05.88 g9aj4tWg.net
常用してなくても動かしてはいるだろ
496:login:Penguin
19/07/06 07:08:26.31 JWtFUONt.net
btrfsのお陰でニュースサイトは信用ならないものだということを再認識した
ボラクルの政治力（）がそれをさせたのだろうか、それとも
497:login:Penguin
19/07/06 07:10:44.85 dmxILAE/.net
>>487
BrtFSってオラクル噛んでんの？
498:login:Penguin
19/07/06 07:54:59.98 RB1jb8Q5.net
「btrfsは透過圧縮が凄い！！」
みたいな宣伝ならまだ分かる。
実際には
「btrfsは他のFSよりも堅牢！安全！」
みたいに、大事なデータこそbtrfsみたいな言い方してるからタチが悪い 。
499:login:Penguin
19/07/06 08:17:26.52 JWtFUONt.net
>>488
RedHatだったか？
500:login:Penguin
19/07/06 11:46:12.10 4pSPVA6e.net
>>483
ストレージなんて導入後１年とか経過したら急激にパフォーマンスが悪化したみたいな話は少なくないわけで。
データ置くんだから色々なハード×運用アプリ×負荷条件×期間で運用して実績積んだ上じゃないと安心
なんてとても言えないんじゃ。
501:login:Penguin
19/07/06 22:08:19.81 PDOwGV40.net
>>488
オラクルが始めたプロジェクト
502:login:Penguin
19/07/06 23:47:58.49 5GCvrZe5.net
オラク●って、会社が関係すると残念なイメージ。
Solaris ヨロなんだけど。
503:login:Penguin
19/07/07 03:37:25.09 DBQmyWlt.net
Btrfs は RAID1 にサイズの異なるディスクを追加してどうヤリクリしてくるか眺めるFS
504:login:Penguin
19/07/07 22:55:34.83 wHKJWVtP.net
メタな話だけどなんでこのスレ犬板にあんの？ム板とかじゃなくて。
505:login:Penguin
19/07/07 23:36:16.83 LnsdbLSY.net
Linuxはファイルシステムの選択肢が多いから、どのファイルシステムを使うのがベストなのかを語るスレだからじゃないの？
ファイルシステムの実装について語るスレだったらプログラム板にあってもおかしくないかもしれないが、
そんなコアな人は5chじゃなくて各OSSファイルシステムのMLとかでやりとりしてるんじゃないの。
自分でコードを書く人向けなのがプログラム板で、ソフトウェアをユーザーとして使う人向けなのがそれ以外の板だと思うけどね。
じゃなきゃハード関係の話題以外はなんでもかんでもプログラム板ってことになっちゃうでしょう。
506:495
19/07/08 06:57:24.61 AnURrIsm.net
>>496
言われてみればそうだな。
確かに多くの種類のファイルシステムを「使う」のはLinuxやBSDユーザーだな。
そしてその実装は5chで議論することじゃないな。
俺がバカでしたw
507:login:Penguin
19/07/08 08:52:01.68 3iNxio62.net
btrfsが問題あるっぽいのはわかる。わかるんだけど、サブボリュームとか便利すぎて乗り換えれない。長らく使っててクラッシュしたの一回だけだし、性能もソコソコだし、バックアップ気軽に取れるし
508:login:Penguin
19/07/08 09:09:49.39 PqTeDeaF.net
>>498
そのファイルシステム
静かに壊れているかもしれないぞ？
試しにbtrfsckをして確認してみた方がいい
509:login:Penguin
19/07/08 09:27:52.78 w3Gb5F7g.net
>>498
その点でいうとzfsがいいんだよなぁ
510:login:Penguin
19/07/08 09:28:36.91 c9rRPEoT.net
btrfs は静かに壊れるという経験はないなあ。
壊れるときはあっという間にエラーログ吐きまくって盛大にぶっ壊れる。
btrfsの唯一(?)凄いのところは、ぶっ壊れても頑張れば相当サルベージできるところ。
面倒くさいからバックアップから復旧するけど。
511:login:Penguin
19/07/08 11:23:09.26 3iNxio62.net
>>499
btrfs check やってみたよ！
問題なかった
zfsは遅いイメージがあるのとライセンス的に……
512:login:Penguin
19/07/08 15:53:33.33 ZuNR36h3.net
個人的にはzfsは速度より古いPCを再利用しようとした時にメモリを食うのがネック過ぎる
削りに削ったFreeBSDですらdedupしてないのに2Gでもきつい
513:login:Penguin
19/07/09 01:21:48.35 ATXfrt0N.net
そんなカスみたいな環境で使うことは想定してないしな
514:login:Penguin
19/07/09 10:36:21.37 PmpiXixe.net
AppleがZFSを諦めたぐらいだからお察し
515:login:Penguin
19/07/09 12:13:42.99 nV0R2UQx.net
Solarisでは鉄板
516:login:Penguin
19/07/09 14:58:02.10 p5VdkUCQ.net
appleがzfsを採用しなかったのは暗号化に対応していなかったからだぞ
ZoLは最近になって暗号化に対応したけどな
517:login:Penguin
19/07/10 11:40:51.24 nTeldC4a.net
/dev/sdc に刺さったPVから作られたLVMがあるんだけど、このディスクを /dev/sdb に
繋ぎ変えたいんだけど、繋ぎ変えるだけでそのまま使えますか？
何か作業が必要？
518:login:Penguin
19/07/10 17:26:14.18 x9KTtfH8.net
ZFSでby-idでしか使ったことないけど
LVM2なら平気なのかな
URLﾘﾝｸ(wiki.archlinux.jp)
519:login:Penguin
19/07/10 20:53:42.68 ystpoF80.net
>>508
lvm.conf で vgscan で除外するデバイス一覧に /dev/sdb が入ってなければOK。
lvm.conf を修正したなら initramfs 再作成もお忘れなく。
520:login:Penguin
19/07/11 11:13:43.42 Wk5uUqUO.net
>>510
㌧
521:login:Penguin
19/07/12 15:39:16.18 Gk95DGyH.net
昔特に考えもなく/bootを除いたOS丸ごとZFSにしてたのを
OS更新に伴って見直そうと思うんだけど
とりあえずメインで使うのは引き続きZFSにして
/boot←fat32(esp)
/tmp←ext4
くらいしか思い付かないんだけど他に良い案とかないかな？
522:login:Penguin
19/07/12 15:53:09.43 Wh9lI3H9.net
もう何年もずっとtmpにはtmpfsを使っている…もちろん推奨などしない
523:login:Penguin
19/07/12 15:57:49.66 pfDdKblt.net
メイン以外の定義を決めてくれないと答えようがない
524:login:Penguin
19/07/12 15:59:17.82 a2hc7ITq.net
/boot ext4
/boot/efi fat32
にするものらしい
525:login:Penguin
19/07/12 16:02:09.99 pfDdKblt.net
bootはxfsにすると高速起動するよ
地味な変更だけど効果は大きいからオススメ
526:login:Penguin
19/07/12 16:34:46.25 Gk95DGyH.net
>>513
それちょっと良いかも。検討してみるよ
>>515-516
/boot xfs
/boot/efi fat32
で試してみるよ。出来ることなら高速起動の方が良いもんね
>>514
特にオススメが無いor迷ったらZFSにするくらいの意味で捉えて頂ければ
527:login:Penguin
19/07/12 17:11:53.45 sHZS1XdB.net
メモリが潤沢な環境で/tmpの下のいくつかのディレクトリをtmpfsにするのは有意だけど
/tmp全体をtmpfsにするのはtmpfsのドキュメントで禁忌にされてるので、やるならまあown riskで
528:login:Penguin
19/07/12 17:12:43.46 sHZS1XdB.net
× 有意
〇 有意義
529:login:Penguin
19/07/12 18:11:52.90 ZSiArtpk.net
むしろ最近のディストロは/tmpまるまるtmpfsが割と普通な気が
その禁忌って書いてあるドキュメントって読んでみたいんだけどどれ？
530:login:Penguin
19/07/12 20:37:16.63 9P7R948V.net
Fedoraがやってるんだから問題ない
とりあえず迷ったらFedoraがどうしてるか見るのがいい
全ての設定はFedoraから流れていく
531:login:Penguin
19/07/12 22:07:44.94 29vUxDs3.net
Fedoraは先進的で実験的らしいから実装一発目の機能とかは怖いイメージ((((；゜Д゜)))
532:login:Penguin
19/07/13 13:05:37.63 fcJUubh5.net
/tmpは普通にtmpfsだろ
/var/tmpは違うけど
533:login:Penguin
19/07/15 09:59:20.11 cdFqCDuE.net
Fedoraに限らずsystemdのデフォルトで/tmpはtmpfsだろ
で、/tmpをtmpfsにするのは禁忌なんて書いてるtmpfsのドキュメントってどこにあんの？
kernel付属ドキュメントでも禁止なんかしてねえけど
URLﾘﾝｸ(www.kernel.org)
534:login:Penguin
19/07/15 11:17:17.22 BML/RJbp.net
RHEL7 は systemd だけど tmpfs ではないな。 (Fedora は人柱？)
例えばメモリ 192GB 搭載のサーバで /tmp に tmpfs 使ってる場合、OS、サービス、
仮想マシン等で190GBメモリを使ってたら、/tmp に書き込める量って2GBだけで
それ以降はスワップアウトって事だよね？
なんか心許ないなぁ。
535:login:Penguin
19/07/15 19:48:13.96 Ii92h755.net
tmpfsに書き込むデータよりも先に他のデータがスワップアウトされるけどな
536:login:Penguin
19/07/15 19:56:32.39 mvcgcerj.net
前提条件がおかしいわな
空きメモリが10%以下の状態とかtmpfs関係なくメモリ不足
537:login:Penguin
19/07/15 20:45:12.78 jA364y5E.net
個人利用で仮想マシン動かしつつ動画編集もやりたいって場合でも
メモリ64GBあれば平気そうかな
今メモリ安いからちょっと奮発すればいける
538:login:Penguin
19/07/15 21:39:47.11 BML/RJbp.net
>>527
解析用途の場合は10%以下でも特にメモリ不足って感じはしないなぁ。
539:login:Penguin
19/07/15 22:57:15.14 smBs7w2W.net
/tmpの容量が気になるほどの巨大ファイルを置くような使い方、する？
540:login:Penguin
19/07/15 23:39:07.37 BML/RJbp.net
>>530
解析用途であらかじめ使うのがわかってる場合は /tmp 以外に NVMe とかで別途高速なデバイス用意する。
しかしミスって /tmp に書くバカもいる。
541:login:Penguin
19/07/15 23:47:09.55 abOBY2uh.net
なんでそんな特定状況で対処もわかってる話でtmpfs使うとか言い出すん？
542:login:Penguin
19/07/16 05:46:05.80 cLso77RL.net
.oO(いまさら禁忌は /tmp じゃなくて /var/tmp だった…なんて言えそうにない雰囲気だな)
543:525
19/07/16 08:19:48.24 pVYPD0D6.net
>>532
RHEL7 では /tmp が tmpfs ではない話の中で、なぜ tmpfs を使わないかの理由について
候補を挙げてるだけで、tmpfs 使っちゃダメって言ってる人とは別の人です。
544:login:Penguin
19/07/16 12:15:47.45 h7Uk/eM5.net
/var/tmpは再起動してもデータが残っていないと駄目だからtmpfsが禁止なんて当然だよな
545:login:Penguin
19/07/16 23:26:48.78 usQ9SNx3.net
インチキなブログのtipsだと/var/logもtmpfs指定したfstab晒してたりして舌がﾚﾛﾚﾛってなる
546:login:Penguin
19/07/17 09:58:56.10 AFXHMKqq.net
まあ昔のSSDだとlogもtmpfsに突っ込みたくなる気持ちは分からなくもない
547:login:Penguin
19/07/17 10:39:03.48 bt1cpQOM.net
まあデメリットとかわかった上で自分がやる分には全然いいと思うけど人に進めるもんじゃないってのはあるね
548:login:Penguin
19/07/17 12:44:08.44 8muhHKDE.net
bcachefsがカーネルにマージされたら即座に導入するわ
ファイル名長が緩和されるのが素晴らしい
現状だとWindowsで解凍可能なファイルがLinuxではファイル名長の関係で
ひと工夫しないと解凍不可能だったりして不便すぎる
549:login:Penguin
19/07/18 03:50:29.60 NlMiN+2I.net
>>539
例えば？
正直ファイルシステムの出来はともかく
ファイル名に関してはext4とかの方が柔軟な気がするんだけど。
550:login:Penguin
19/07/18 10:30:47.46 qpBAOMYJ.net
例えばも何もファイル名長って書いてあるやん
そのあたりの諸元でLinux系fsの大半に問題が出るのは常識だと思ってたけど
551:login:Penguin
19/07/18 11:22:32.09 JDRv+q9U.net
LVMで確保されたストレージのサイズ変更を
久しぶりにやってみた。lvextendでLVの
サイズを変更して、xfs_growfsでユーザから
見える空き容量を増やす簡単なお仕事だが、
何度やってもドキドキしちゃうな。
552:login:Penguin
19/07/18 12:36:42.61 /3OmbnoQ.net
>>539
こんなの作られてたのか
btrfsはダメみたいだしZOLは導入めんどくさいから
出来が良いといいんだけどなぁ
553:login:Penguin
19/07/18 13:37:58.94 mg7cTxgX.net
bcachefsのディスク上のレイアウトってまだドキュメントとしてはまとめられてないみたい？
ext4でいうURLﾘﾝｸ(ext4.wiki.kernel.org)
btrfsでいうURLﾘﾝｸ(btrfs.wiki.kernel.org)
みたいな奴
554:login:Penguin
19/07/18 18:31:40.18 LlSTNp3u.net
>>542
拡張ならまだよい。
縮小するお仕事は、大変だよ？
555:login:Penguin
19/07/18 19:03:55.38 NlMiN+2I.net
>>545
それでファイルシステム破壊したことあるw
家のサブ機だったから自己責任だったけど
あれ全く縮小の準備が整ってなくても何の警告もなしに実行するんだね。
少なくとも2016年では。
556:login:Penguin
19/07/18 19:45:18.30 YgfrHJvj.net
>>546
おれもルートファイルシステムを縮小しようとして、起動しなくなったことがある。
バックアップから戻した。以後試してない。
557:login:Penguin
19/07/19 22:22:13.23 9+hwCVUH.net
bcachefsの開発者ってpatronで資金提供者集めてるんだな
558:login:Penguin
19/07/19 22:29:05.21 DJejSRGa.net
マジか
寄付しとこ
559:login:Penguin
19/07/19 23:01:06.73 rvNOTbce.net
大口スポンサーの要求が参照リンクの実装だったらしく
今急ピッチで実装しているみたいだな
560:login:Penguin
19/07/19 23:01:58.65 rvNOTbce.net
これが実現するとbtrfsやxfsのような形式での重複排除も可能になる
561:login:Penguin
19/07/19 23:21:10.11 KCjCfW9P.net
なんでbcacheなんか拡張することにしたのか疑問だったけど
このKent Overstreetって人がbcache本体の作者でもあったのか
ずっとfacebookがやってるやつとごっちゃになってたわ
562:login:Penguin
19/07/19 23:28:54.90 rvNOTbce.net
bcacheの作者がbcachefsの作成に移行した影響で
大元のbcache自体が全然更新されていないという状況になってる
オープンソースって実際には1人抜けたら立ち行かないようなプロジェクトばかりよね
563:login:Penguin
19/07/19 23:38:05.63 Ss290YYV.net
bcashefsのベースになってるから下手に弄れなくなったんだろ
あるある過ぎて笑えんけど
564:login:Penguin
19/07/19 23:58:38.95 IN7Btozr.net
BcachefsのGithubを見たら案の定
コメントが殆どない、他人に触らせる気の感じられないコードだった
URLﾘﾝｸ(github.com)
作者にしかメンテ出来ないとはまさにBtrfsの再来
参考までにxfs
URLﾘﾝｸ(github.com)
コメントが丁寧に書かれて読みやすい
565:login:Penguin
19/07/20 03:51:57.90 WfYnTXWF.net
ext4に続いてF2FSも大文字小文字を区別しないようにするオプションが作られているらしい
566:login:Penguin
19/07/20 06:23:21.98 Mi7o95f1.net
どこ読んでるかわかんないけど、コメントちゃんとあるように見えるけど
567:login:Penguin
19/07/20 08:08:29.10 bPfJoXMV.net
寄付なんて殆どが直接募集した奴が何割吸い取るかもわからない詐欺みたいなもんだぞ
568:login:Penguin
19/07/20 08:44:45.83 /RW5DImO.net
本人が集金してるんですがそれは
569:login:Penguin
19/07/20 09:05:30.53 DSGhLxxU.net
Linux上のZFSはLinux 5.0以降でSIMDサポートを復元する方法を考え出しました
URLﾘﾝｸ(www.phoronix.com)
近いうちに、新しいZFS On Linuxベンチマークを出すようにします。
570:login:Penguin
19/07/20 22:18:28.70 zeHgvHr/.net
なにその機械翻訳みたいな文章
571:login:Penguin
19/07/21 07:22:04.94 ROhY0MNF.net
>>561
chromeで自動翻訳してくれるからそのまま貼った。
572:login:Penguin
19/07/23 03:28:06.87 SCZ5bl9v.net
>>454
Ext2Fsdをインストールしてるとリムーバブルメディアを取り外せなくなるからアンインストールした
>>459
ファイルを更新した直後に青画面や停電などでクラッシュすると
次回起動時に該当ファイルが0で埋められる挙動があってデータを失ったことがある
ソフトはバックアップを作ってから更新するタイプだったがご丁寧にもバックアップまで0で埋められた
573:login:Penguin
19/07/23 03:45:44.40 SCZ5bl9v.net
>>440 >>445
bcachefsは知らんが
bcacheは安定性に難あり
条件を満たすとカーネルがメモリやスタックの汚染を報告して十数分後から数時間後にシステムが確実にクラッシュする
多数ある条件を回避していって最近になってようやく安定稼働に持ち込めた
574:login:Penguin
19/07/23 03:47:57.79 eYVlzNHh.net
それファイルシステムのせいじゃないだろ
575:login:Penguin
19/07/23 07:13:59.96 y0KQNHxf.net
xfsも一時期酷かったけど今は高評価だし、直ってれば何でもええよ
576:login:Penguin
19/07/23 08:55:55.62 gjJlsP0Z.net
何かを利用するって事は、その下側の使ってる部分の品質を上回れない事でもあるからなぁ
安定したばっかのを使うってのは（ｒｙ
577:login:Penguin
19/07/23 10:34:20.54 y0KQNHxf.net
そういうのを使ってあーでもないこーでもないと情報を交換したりバグを報告するのがOSSユーザーの嗜みであり楽しみでは？
578:login:Penguin
19/07/26 00:00:48.02 jkGHHOAL.net
今まで何もわからずUFA使ってたけど新NAS作ろうとして調べれば調べるほどファイルシステムが選べないわ
どれも一長一短あるしまるでリーマン予想を解いているみたいだ
579:login:Penguin
19/07/26 00:23:48.04 kTNN9g4P.net
いやxfs一択でしょ
580:login:Penguin
19/07/26 11:10:43.69 g7Og2WUg.net
XFS一択なの？
581:login:Penguin
19/07/26 18:49:37.46 /zAUPOSD.net
windowsから読み書きできない時点で、
XFSのせいではないが、候補から外したくなる
582:login:Penguin
19/07/26 19:45:54.44 x3ulgDdb.net
NASだぞ？
583:login:Penguin
19/07/26 20:48:37.30 /zAUPOSD.net
緊急時、データだけでも確保したいときのことを考えちゃうんだよ
XFSって、プラットフォームによってはLinuxからでも読めないことあるしなぁ
市販のNASで一度懲りたわ
584:login:Penguin
19/07/26 21:09:09.29 McqAipQp.net
そんなこと言い出したらNTFS最強って話になってくるし
585:login:Penguin
19/07/26 21:12:57.73 rbHyg+XJ.net
読めるファイルシステムでバックアップ取りなよ
586:login:Penguin
19/07/27 01:35:01.82 Ut6QMCX/.net
windows関係ないけど、xfsの何がという話をしないから
信心深いのかな？くらいにしか思わない
自分ならext4で無難かな
587:login:Penguin
19/07/27 10:50:20.98 95325KkT.net
>>577
RHEL7 のファイルシステムサイズの上限が ext4 は 50TB、xfs が 500TB。
2U サイズのラックマウントサーバだと 3.5インチHDDが12本は載るからext4
だと１パーティションに収まらないのよね。
上限は RHEL6 の時は 16TB だったからその頃から xfs を選択せざるを
得なくなった人が多い。
RHEL7 以降デフォルトが xfs になってるから不具合も一番潰されてるだろう
から、一番安心して使える。
何を以て安心っていうかというと、どれだけ多くのディスク/RAID装置で、
どれだけ多くの故障パターンを経験して来たかだと思ってる。
なので普及率はバカにできない。
>>574
カーネルを新しくするか逆に古くする、マウントオプション色々試す、はやった？
588:login:Penguin
19/07/27 11:50:18.10 c6O4WNXP.net
>>565
仮想マシンのゲストのWindows(10とXP)がクラッシュしたときも再現したのでNTFS実装の挙動で間違いない
俺はそれを見たとき対策を諦めた
589:login:Penguin
19/07/27 11:52:02.12 c6O4WNXP.net
同じNTFSでも2000ではファイルを閉じるときに必ず物理書き込みする挙動があって
クラッシュしたときにファイルが壊れる経験は皆無だった
590:login:Penguin
19/07/27 11:53:55.94 c6O4WNXP.net
XFSの噂はよく聞くが、どのベンチマークでもメタデータ更新系の成績がかなり悪い点は気になっている
細かいファイルをよく扱うLinuxとは相性悪いんじゃないだろうか？
591:login:Penguin
19/07/27 12:09:30.28 RKarvGRO.net
複数のファイルの遅延書き込みを溜め込みつつ、特定のファイルのフラッシュが必要になったら
確実にそのファイルへの変更結果をファイルシステムに矛盾が発生しない順序で
即座に物理層に反映・・・って、実は思ってる以上に複雑
その辺りは資本の力で開発されたファイルシステムに軍配が上がる
592:login:Penguin
19/07/27 13:47:26.05 6zG70b0r.net
遅くてもいいから壊れないものを
593:login:Penguin
19/07/27 13:47:41.85 Ut6QMCX/.net
>その辺りは資本の力で開発されたファイルシステムに軍配が上がる
んなこたーない、ntfs厨はもうこないでほしい
594:login:Penguin
19/07/27 14:09:34.66 RKarvGRO.net
何故NTFSに限定したのだろうか・・・
595:login:Penguin
19/07/27 14:17:25.71 Ut6QMCX/.net
限定したよ、だから何
帰れ
596:login:Penguin
19/07/27 14:34:02.96 SmtkTd2f.net
上にもあるが現在は正解がないというのが真実な気がする
正解がないので各派閥が宗教のように自分が使っているFSだけを信じ続けている
デジタルなのにやってることは人類が太古から続けているアナログ的な宗教に行き着くというのが感慨深い
597:login:Penguin
19/07/27 14:47:59.82 RKarvGRO.net
商用のファイルシステム以外はzfsとextの中間に位置する様なシロモノがないからな
その辺りにbtrfsが位置する予定だったんだろうけど、蓋を開けてみたらアレだったしな
598:login:Penguin
19/07/27 15:44:12.94 ynbj8IZE.net
>>578
ARMアーキテクチャのNASで使われているXFSは、
x86アーキテクチャのマシンからは、
エンディアンの違いで読めないことがあったんだよ。
（知ってたらゴメンね）
読む方法はある（シェアウェア）らしいし、
最近はバグらしきもの（FSかドライバか）が取れたらしいけど。
>>580
Linux物理マシンをext3で使ってたとき、
sync コマンドと、ALT＋SysRq＋s はなんか習慣的に押してたなw
まぁ、気休め程度にしかならんだろうけど。
599:login:Penguin
19/07/27 16:33:24.47 vPZ9hNH2.net
zfsさいっょ
600:login:Penguin
19/07/27 19:23:55.42 mQu6FNvv.net
クラッシュ耐性上げるにはCoWしか無いんだよな
bfrfs不安定と言われているけど突然の停止にはxfsやext4より壊れにくい
601:login:Penguin
19/07/28 02:04:51.78 OAxz9Pyz.net
xfsにもフォーマット時のオプションで
CoWが可能になったの知らないのか
602:login:Penguin
19/07/28 09:43:26.39 8zKDGL71.net
>>591
メタデータについてはジャーナリング機能の実装段階でそれ相応の物が
入ってて、CoWでは耐性上がりようがないって認識だわ。
そもそもシステムコールで明示的に呼び出さない限り CoW にならないわけで、
CoW ではなくスナップショットファイルシステムというべきじゃないかな。
603:login:Penguin
19/07/28 21:18:10.31 CB5E+oZy.net
今までファイルが壊れた経験があるファイルシステム
・btrfs
・ntfs
604:login:Penguin
19/07/29 10:42:58.53 AMCKbOHw.net
ファイルシステムの頑健性っていうのはソフトウェアのレイヤーで全てが語れるわけじゃない
あるファイルシステムのある機能が、あるディスクアレイでは頑健性を上げることもあれば逆もありえる
仮想マシンだってそう、むしろレイヤーが重なる上にハードウェアチートまであるから
クラッシュ時の挙動がファイルシステム側由来なのかなんてfs設計者でも簡単には分からん
605:login:Penguin
19/07/29 19:08:03.66 4QwhTaJH.net
スナップショットとシンプロビジョニングはオープンソースだとテストのやり込みが足りない・
テスト量がシステムの修正に追いついていないせいで安定しないイメージだわ。
これら＋RAID-Z/VRAID系は長期利用時のフラグメンテーション対策がお留守な感じなんで
スナップショット等が必要な業務環境でオープンソース系ファイルシステム使うのは怖い。
606:login:Penguin
19/07/29 19:58:02.26 zJDJcz0l.net
RAID-ZってZFS以外使ってるんだっけ?
今のSolarisとFreeBSDとZoL,どれが一番安定してるんだか
607:login:Penguin
19/07/29 22:46:46.27 4QwhTaJH.net
>>597
Linux 外だが Isilon の OneFS がストライプ長可変なのでほぼ同じもの。
こちらは RAID-Z4 相当まで実装してる。
608:login:Penguin
19/07/30 03:59:06.50 qLodTkR5.net
>>597
Solaris
609:login:Penguin
19/07/30 05:28:26.62 HF8yxYK2.net
>>597
意味がわからないけどRAID-Z=ZFSだろ？
610:login:Penguin
19/07/30 15:41:25.39 0CM/a0KN.net
>>600
それは>>596に言ってくれ
611:login:Penguin
19/07/31 16:24:21.03 esTiVmHP.net
JFSやXFSで満足しないならもうLinuxを棄てるしかないんや
612:login:Penguin
19/07/31 16:49:32.80 Wv68Jyik.net
>>602
バイバイsoralis
君のことはもう忘れたよ
613:login:Penguin
19/08/01 04:08:51.36 BMyzMKl4.net
次元、五右衛門 久しぶりだなー
カール 今日はご主人様と一緒じゃないのか？
（カールという名前はわしの他はもう Soralis様しか知らないはずだ。）
Soralis？ そうか、お前のご主人は Soralisってえのか..。
.....
.....
銭形: Oracleはとんでもないものを盗んでいきました。
それは貴方のファイルシステムです。
614:login:Penguin
19/08/01 05:02:38.99 rA7aLj1x.net
もしかして：Solaris
615:login:Penguin
19/08/01 07:08:56.64 /5jO1LjD.net
soralis?solaris?
誰でぇ、それは
616:login:Penguin
19/08/01 12:27:48.03 FPgX7+/Y.net
ソラージ
617:login:Penguin
19/08/03 04:46:19.02 okf0cS5M.net
結局色々やってext4に行き着いた
618:login:Penguin
19/08/03 07:21:09.50 67ZtkjFh.net
アップデートもないしほとんど使っている人はいないと思うけどメインのNoteの/homeをnilfs2で運用初めてそろそろ10年。
それ以降PC自体が3代目でPC替えたらDDではなくてcpで移したので10年連続で同じパーティションを10年運用したわけではないけど、FSが飛ぶような深刻な自体は使い始めに操作を間違ったときくらい。
Nilfs2の仕様上FSフルにしてしまうと面倒なことが起こるけど、それも10年で2回程度。
概ね24時間分ぐらいは遡れるようにしているので間違って書き換えたり消したりしてもすぐ取り返せる安心感が嬉しくて使っている。
といってもその作業も10年で3回程度だけど。。。
619:login:Penguin
19/08/07 15:48:47.13 tHruglCb.net
CoW版のXFS使ってみたけどめっちゃ安定してるわ
完全に常用も可能な漢字
620:login:Penguin
19/08/07 16:06:32.13 D6dfz/XB.net
そんなゴミみたいな煽り文句は他所でやれ
621:login:Penguin
19/08/07 16:13:26.51 VOvKzyRf.net
最低限どういう手法でテストしたのか位は書いてもらわんと何も意味ないわな
622:login:Penguin
19/08/07 19:19:11.92 eVw1mf5N.net
そのくらいゆるふわ意見だと我が家のbtrfsも一度もデータ飛んだこと無いし、動画圧縮で凄く容量削減してるし、山ほどスナップショット撮れてるし、ものすごくtrimできるし、死ぬほど安定してる
623:login:Penguin
19/08/08 16:07:29.83 BnM28ZaO.net
100台月ぐらいメタデータ・シーケンシャル・ランダムアクセスの混在負荷テストすりゃいいかなと思っている
624:login:Penguin
19/08/09 12:25:30.55 2xxnQ7nf.net
Ubuntu 19.10からZFSのサポート強化 2019/08/09 08:33 後藤大地
URLﾘﾝｸ(news.mynavi.jp)
Canonicalは8月7日(米国時間)、「Enhancing our ZFS support on Ubuntu 19.10 - an
introduction - Ubuntu Blog｜Ubuntu Blog」において、この秋にリリースが予定されて
いる「Ubuntu 19.10」のデスクトップ版からZFSのサポート機能を強化する予定だと伝えた。
このまま順調に開発が進めば、Ubuntu 19.10 Dekstopでは実験的という位置づけながらも、
ルートファイルシステムをZFSで構築することが可能になると見られる。
Canonicalは今後、ZFSの採用範囲を広げるとしており、順次新しいUbuntuでZFSの利用を
拡大することが予想される。また、デスクトップ版は最初の取り組みとしており、今後
サーバ版にもZFSの適用が拡大する見込み。ZFSは人気の高いファイルシステムであり、
多くのユーザーに歓迎されると思われる。
LinuxにおけるZFSの利用に関してはライセンスにおいて長い間疑念が存在している。
Canonicalは数年前にライセンスに関して調査を行い、LinuxにおけるZFSの利用はライセン
ス違反にはならないという結論を出しており、それ以降、UbuntuでZFSを利用するための
取り組みを続けている。
ZFSはモダンなファイルシステムの1つ。ストレージ・アプライアンスやストレージ・シス
テム、NASで広く採用されている。提供されている機能が豊富で、さまざまな稼働実績が
あり、ユーザーから高い支持を得ている。Linuxディストリビューションの中でも高い人気
があるUbuntuでZFSが利用しやすい状況になることで、ZFSの利用範囲が広がると見られる。
625:login:Penguin
19/08/09 16:56:19.31 9F/SVKov.net
文字数の割には情報量の薄っすい記事だな。
具体的にどう拡大するのか何も書かれていない。
626:uin
19/08/09 19:21:58.09 rfEV2Og4.net
Ubuntu は技術的という意味以外で危ない橋を渡ってくれていいな。
Debian派なので、使ってないが。
627:login:Penguin
19/08/10 06:20:36.38 ZWJAdRCH.net
LinuxにはXFSやJFSという素晴らしいFSがあるというのに
btrfs(笑)
628:login:Penguin
19/08/10 23:06:34.79 2XkczDqc.net
そろそろOSやデバイスによらない究極のファイルシステムを誰か作って欲しいわ
629:login:Penguin
19/08/11 00:16:24.96 oUkRG+KV.net
求められてるものが違うから無理でしょ
630:login:Penguin
19/08/11 00:55:00.87 Uf+U5nYS.net
そもそもファイルシステム自体がOSの一部だからな
631:login:Penguin
19/08/11 01:10:53.54 QM4D0Z+6.net
?
632:login:Penguin
19/08/11 04:25:14.47 ha8y5VIz.net
FAT32というほとんど全ての環境でサポートされている素晴らしいファイルシステムがあるぞ
633:login:Penguin
19/08/11 08:25:51.10 fbfbhXo0.net
ていうか「普通に」使う分にはFAT32でも十分な気がする。
そんな馬鹿デカい容量を扱わんし
634:login:Penguin
19/08/11 09:45:05.49 iIn5DM/X.net
OSの一部というよりOS設計に密結合しとるから、ファイルシステムだけ分離してもあまり意味が無いというか
635:login:Penguin
19/08/11 13:26:31.69 cuLqexzl.net
理想のファイルシステムって何よ？
636:login:Penguin
19/08/11 13:48:18.92 maGT1VI+.net
軽量なZFS
637:login:Penguin
19/08/11 15:23:31.80 zxPpiGnO.net
OSから独立していても、特定のOSや企業が関わると党派性の餌食になって正当な評価が得られなくなってしまうので
具体的にはAppleとMicrosoft
アップルに関わると不当に高評価しようとする勢力によって歪められ
マイクロソフト由来のものは不当に低評価される傾向にある
前者はMac/BSD採用前後のZFSを巡る扱いにおいて顕著であり
後者はNTFSの長年にわたる(低)評価について異論を待たない
まあ平たく言えばゲハ脳のリンゴ信者の声ばかりでかくて実態を反映してない
ノイジーマイノリティうぜえって話で終わる
638:login:Penguin
19/08/11 20:51:04.63 b1ksZLfY.net
>>626
バグが無くて、使い方によらず高速で、
いかなる時もデータが失われず、
物理的な制限もないとか。
現状の物理的な容量を超えて、
無制限に記録できたりしたら、
喜ぶ人ば多いんんじなかろうか。
639:login:Penguin
19/08/11 21:29:32.28 3JMjmUyB.net
>>624
FAT32じゃだめ理由は容量じゃなくて、
セキュリティとUnicode対応だよ
セキュリティは、システムドライブとして使うなら必須だが、
いろんなマシンに接続する外部ストレージだと意味ないので無くても良い
でもUnicode対応は必須
640:login:Penguin
19/08/12 01:09:10.91 d4sdreTy.net
FAT32はUTF16LEに対応している
641:login:Penguin
19/08/12 02:29:50.29 NZmR/0AL.net
>>626
完成したReiser4
642:login:Penguin
19/08/12 02:40:46.93 NokuNn6B.net
>>630
>>631でも書かれてるとおりUnicode対応してると思うけど？
643:login:Penguin
19/08/12 06:28:53.82 NokuNn6B.net
と思ってざっと検索してこのページを見付けてそして絶望した。
URLﾘﾝｸ(stackoverflow.com)
644:login:Penguin
19/08/13 02:42:34.19 aG+MUqdm.net
exFATが4G超えもUNICODEも対応した理想の外部ストレージ用ファイルシステムになるはずだったんだけどな
ライセンスの問題なのかlinuxではネイティブ対応せず使い勝手が悪い
FAT32がWindows/Linux/MacどころかBIOSが認識してフラッシュの書き換えに使えるのと比べると汎用性が低い
645:login:Penguin
19/08/13 04:50:56.59 hjIX5LBa.net
>>635
MSの規格を使うと、惑わされてろくなことがない。
646:login:Penguin
19/08/14 06:07:09.42 j+CrCYgD.net
LinuxでのexFATはもうすぐネイティブサポートされるかもしれない
サムスンがクローズドで開発していたんだけど間違えてgithubに公開したらGPL違反だとバレてオープンソース化した
それをLinuxのメインラインに取り込んでしまおうと言う議論がされている
特許についてはMSが去年OINに参加したから問題ないと思われる
647:login:Penguin
19/08/14 06:16:42.69 446s3CFR.net
こマ？
648:login:Penguin
19/08/14 08:15:42.47 wXe1OdwF.net
そういえばOIN入ってたなmicrosoft
昔はOINの敵だったのにかわったもんだ
649:login:Penguin
19/08/14 12:22:52.78 mQ9mwTdn.net
Githubで公開しちゃった奴は、こうなる流れを見越していたんか。
650:login:Penguin
19/08/14 14:26:38.36 wc+Iy5bm.net
公開と言うよりも正義の告発だろう
GPL違反に加担する行為に良心の呵責が耐えられなかったのさ
651:login:Penguin
19/08/14 21:45:17.18 AVLJRAxc.net
なんか、彼の国らしい話だな
652:login:Penguin
19/08/15 05:46:12.96 W1sEpxJ4.net
>>637
MSが加盟した時点で、特許問題クリアされてるし、MS側からカーネルドライバーのリファレンス実装や、ユーティリティが出てくるの時間の問題なように思うけど。
653:login:Penguin
19/08/15 11:23:41.51 wrlhxu7n.net
DropboxはLinux上のZFS、XFS、Btrfs、eCryptFSのサポートを復活させています
URLﾘﾝｸ(itsfoss.com)
Dropboxベータビルドにより、ZFS、XFS、Btrfs、eCryptFSファイルシステムのサポートが追加されます
654:login:Penguin
19/08/15 20:20:35.65 la00X25b.net
>>644
あ！
去年の今頃ファイルの上にext4のファイルシステムつくってループバックマウントしたんだけど
またXFSでdropbox使えるようになった！
655:login:Penguin
19/08/15 21:41:24.78 BwZ8qz5R.net
>>644
どもです
656:login:Penguin
19/08/15 23:57:45.40 q1J1ZnUl.net
>>644
homeをnfsマウントしてたらやっぱりDropboxつかえないんだよね？
657:login:Penguin
19/08/21 22:13:21.76 1QPw9kaw.net
FAT32がUnicodeに（一応）対応していたとは知らなんだ。
658:login:Penguin
19/08/21 22:36:35.26 1QPw9kaw.net
ついでに言うと日本産業規格で定義されているとも知らなんだ（俺が無知すぎるだけw）
659:login:Penguin
19/08/21 23:41:34.91 M7Fu+WRI.net
FAT32どころかFAT16もFAT12も同様
660:login:Penguin
19/08/21 23:51:24.49 0CXkpgBN.net
「どころか」の使い方おかしいだろ
661:login:Penguin
19/08/22 01:16:51.67 dj60c2S0.net
「AどころかBもX」
と言った時は
「Aは前提として（時として当たり前に）XだがAよりXっぽくないBもまたXである（驚きの感情）」
という含意があるんだから，使い方としては全うな部類だろう。
FAT32はU
662:nicodeに対応してるけど，それより他の機能で劣るFAT16・FAT12にさえUnicode対応である（驚きの感情）
663:login:Penguin
19/08/22 05:33:27.83 1Yr3egmY.net
流れから、FAT32はJIS規格だけど古いFAT16,FAT12もJIS規格だ（まぁ順当にそうだろう）、という解釈も
664:login:Penguin
19/08/22 06:15:16.86 dj60c2S0.net
たしかに。
665:login:Penguin
19/08/22 11:06:57.22 NSVYAGiU.net
ファイルシステムはサイズがPBを超えてからが勝負
666:login:Penguin
19/08/22 12:20:02.77 m9kjglry.net
Unicode対応はFAT12でもVFATなら対応可能って奴じゃないの?
MS-DOSで見ると謎の文字列になるやつ
FreeDOSでもそうじゃなかったっけ?
UEFIはどうだったか覚えてない
>>655
個人で勝負に挑むには、月間の消費電力どれくらいになるんだろう
667:login:Penguin
19/08/22 12:21:32.17 jWTG6YZX.net
FAT64を作れば最強じゃね？
668:login:Penguin
19/08/22 12:36:54.87 m9kjglry.net
新たに作らなくてもexFATでいいんじゃね?
669:login:Penguin
19/08/22 16:22:24.42 pq9swZ6w.net
誰かVirtual Data Optimizerを試した
人はいませんか？RHEL 7.5から使える
重複排除の機能拡張っぽいのだが。
URLﾘﾝｸ(github.com)
670:login:Penguin
19/08/22 16:40:08.64 c/3upDZj.net
>>550
実装できたみたいね
671:login:Penguin
19/08/25 20:40:25.94 hTk0r0Sf.net
exFATはほぼFATじゃないでしょ。少なくともFAT32やらとはかなり互換性を失なってる…筈。
672:login:Penguin
19/08/26 14:38:35.90 ebuP7us/.net
ディスクの扱える最大容量が違うのに
互換性なんて持たせられるはずがないべ
673:login:Penguin
19/08/26 18:10:15.54 Q2M/7GD/.net
bcachefsの登場で
中身のファイル名が長すぎて解答できないRARファイルが
いよいよ解凍可能になるぜ
674:login:Penguin
19/08/27 23:26:23.88 cl90n3Lm.net
40年前に100EBのファイルシステムを想定したFS作ってればよかったのに
675:login:Penguin
19/08/28 00:51:29.92 roj4LxzO.net
そんなの作ってもメモリ不足で使えねえよ
676:login:Penguin
19/08/28 02:44:43.76 K9W23MUl.net
大容量でもメモリ不足にならないよう作れるだろうに。。
677:login:Penguin
19/08/28 03:13:56.82 XY99YJWD.net
仮にメインメモリが不足しなくっても上位bitが無駄になりまくって記憶媒体の無駄遣いになってたろう
当時のKB単価知らんのけ？
678:login:Penguin
19/08/28 03:24:40.69 jakMXSf+.net
俺がコンピュータを使い始めた頃は1MBうん十万なんて時代だったしな
679:login:Penguin
19/08/28 07:49:31.84 j5W+ovEv.net
ビット単位で惜しんで実装する時代だったな
そんなもん設計しても実装して運用出来るメモリ容量がない
680:login:Penguin
19/08/28 07:59:58.47 db/ocE9c.net
>>664
64KBあれば個人には使い切れない(笑)
と云われていた時代に何を云うとるか(笑)
681:login:Penguin
19/08/28 08:09:15.90 jUTn4eZr.net
ﾋﾞﾙｹﾞｲﾂ「640KBのメモリがあれば十分」はデマだった [無断転載禁止]c2ch.net
ｽﾚﾘﾝｸ(prog板)
ビルゲイツが言ったとされる「640KBのメモリがあれば十分なはずだ」は実はデマでした
本人自ら行っていないと明言しており、第三者の調査でもそのような発言は見つかっていません
URLﾘﾝｸ(pc.watch.impress.co.jp)
> 「640KBのメモリがあれば十分なはずだ」なんてことを言った覚えはないんだけど。
> 2005年のWinHECは、ビル・ゲイツ会長のこんなジョークともボヤキとも受け取れる言葉で始まった。
その発言の動画
URLﾘﾝｸ(www.youtube.com)
682:watch?v=ElDgsQAzrLo > Bll Gates at WinHEC. Claimed to have never said that computer would never need more than 640K memory インタビューで、そのようなことは言っていないと明言しています。 https://web.archive.org/web/20110202030010/http://www.usnews.com/usnews/biztech/gatesivu.htm Q. Did you ever say, as has been widely circulated on the Internet, "640K [of RAM] ought to be enough for anybody?" No! That makes me so mad I can't believe it! Do you realize the pain the industry went through while the IBM PC was limited to 640K? The machine was going to be 512K at one point, and we kept pushing it up. I never said that statement?I said the opposite of that. The '640K' quote won't go away -- but did Gates really say it? (ビルゲイツは本当にそういったのか？） http://www.computerworld.com/article/2534312/operating-systems/the--640k--quote-won-t-go-away----but-did-gates-really-say-it-.html 第三者の調査でも、根拠なしの主張を根拠に主張しているだけ（ループしてる）で 最初の出典が存在しないことを突き止めています。 http://quoteinvestigator.com/2011/09/08/640k-enough/ つまりビルゲイツは「640KBのメモリがあれば十分なはずだ」なんて 一言も言っていません。 これは英語サイトでは当時検証済みの話です。 情弱日本人が知らないだけです。
683:login:Penguin
19/08/28 08:09:50.50 jUTn4eZr.net
いつの間にか「ビルゲイツ 640KB」で検索したら↑のスレが
一番目に来るようになってるなｗ
684:login:Penguin
19/08/28 08:20:42.08 U92vyvJf.net
>>667
お前が設計したら無駄になりまくるからといって
それがもっとも効率が良い設計だと思わないで
685:login:Penguin
19/08/28 08:38:43.64 XY99YJWD.net
>>673
100EBを表現しなければならない可能性のあるとこには必ずそれだけのbitが必要になる筈なんだが
可変長符号化だってコスト0（bit）って訳じゃないんだぞ
686:login:Penguin
19/08/28 08:47:45.84 /ip8C1e4.net
考え方次第で最初に全サイズを読み込んでそれに基づいたbit割り振るようにすればいいだけなのでは？
687:login:Penguin
19/08/28 09:27:43.57 XY99YJWD.net
そのサイズは何bitでわかる？ｗ
688:login:Penguin
19/08/28 10:29:36.59 U92vyvJf.net
>>674
100EBを表現しなければならない状況でそれに必要なbitを使うのは無駄ではない
問題は100EBを表現しなくてもいい状況で無駄に使わないことだろ
689:login:Penguin
19/08/28 10:33:24.68 XY99YJWD.net
>>677
だから1byteなのか2byteなのか3byteなのかの可変長符号にもコスト掛かるっつってんだよｗ
690:login:Penguin
19/08/28 11:26:30.77 U92vyvJf.net
>>678
コストが掛かるのは当然だ
コストゼロでなければ「無駄になりまくって」るというならお前の頭がおかしい
691:login:Penguin
19/08/28 12:33:20.72 XjV2vzUW.net
そもそも容量増加スピードなんてのは予測できるわけでそれに合わせてFSもロードマップ作って拡張すりゃよかったんだよ
692:login:Penguin
19/08/28 21:30:25.06 XY99YJWD.net
当時のKB単価もビット判定やら何やらに掛かるステートも知らずに、後出しで難癖付けるだけなんて簡単でいいよな
てかそう思ったんならおまえが普及させりゃ良かっただろ�
693:ﾁていう
694:login:Penguin
19/08/28 21:35:39.43 +xLGKmxQ.net
今だと瓦HDDに最適化したファイルシステム開発したら歓迎されそう
（もうどこかやってるかな？）
695:login:Penguin
19/08/29 01:12:11.08 VQiAWJJ4.net
瓦HDDの中でホスト側で制御するものは、その手のファイルシステムを前提にしている
696:login:Penguin
19/08/29 01:16:27.76 VQiAWJJ4.net
瓦は読み込みと書き込みの最小単位が異なる点でSSDと同じなので
SSD向けのファイルシステムが効果的な可能性が高い
例えばCoWやバケット単位の管理を採用したやつ
697:login:Penguin
19/08/29 06:53:52.44 yqJY2zQ1.net
>>637
URLﾘﾝｸ(www.phoronix.com)
> Microsoft Publishes exFAT Specification, Encourages Linux Support
ｷﾀ━━(ﾟ∀ﾟ)━━!!
698:login:Penguin
19/08/29 08:24:17.14 ayv/fTUM.net
>>685
やっぱりMicrosoftは正義やな
699:login:Penguin
19/08/29 09:17:06.65 57E44Kd+.net
最近は反MSの連中よりMSのほうがOSSに貢献してる
700:login:Penguin
19/08/29 09:31:29.66 oTY9cNJu.net
ntfsも公開してくれよん
701:login:Penguin
19/08/29 10:37:08.37 IgCGENYH.net
>>685
ｷﾀ━━(ﾟ∀ﾟ)━━!!
702:login:Penguin
19/08/29 11:53:24.06 ayv/fTUM.net
>>688
NTFSは公開してもファイルシステムの高度なセキュリティ能力を
Linuxにマッピングできないのであまり意味がないな
703:login:Penguin
19/08/29 12:26:30.72 5xSjyKa3.net
>>682
瓦最適化はWDの中の人がbtrfsにパッチ投稿中。
704:login:Penguin
19/08/29 18:23:14.00 17OYqypV.net
Microsoft、Linuxカーネルで公式に「exFAT」サポート
URLﾘﾝｸ(www.itmedia.co.jp)
705:login:Penguin
19/08/29 18:31:46.62 3gIOV6hV.net
>>691
はえー。俺の鯖ちょうど瓦でbtrfsだわ、ありがてえ
706:login:Penguin
19/08/29 20:54:27.48 7ODgbVNJ.net
>>687
反MSって具体的になに？Oracleとか？
707:login:Penguin
19/08/29 21:12:57.84 V76BsNE3.net
Windows Storage Server 2016の重複排除機能、優秀すぎてﾜﾛﾀ
708:login:Penguin
19/08/29 21:56:07.88 71eCL6Dr.net
>>689
どちらかというと、ユーティリティ側の出来がよくなってほしいな(´･ω･`)
今、fsck.exfatがチェック出来るだけ状態だからね。
マウントするだけならfuse経由でできるし。
709:login:Penguin
19/08/29 22:30:20.18 /Ysvkkai.net
>>695
今のところ重複排除がまともに運用できるのWindows Serverだけだな
ZFSも一応使えるけど使う人居ないだろって感じの実装
710:login:Penguin
19/08/30 01:10:38.60 49Usa2R4.net
>>690
同じ理由でextXもWindows上では使い勝手が非常に悪い
NTFSもextXもシステムに特化しすぎて細かい仕様がなじまない
低機能なFATがいまもデータ交換用に普及してる理由でもある
711:login:Penguin
19/08/30 01:11:23.89 49Usa2R4.net
exFATの構造
URLﾘﾝｸ(homepage3.nifty.com)
712:login:Penguin
19/08/30 01:18:35.79 49Usa2R4.net
exFATは他の近代ファイルシステムに合わせてメタデータをファイル化したのはいいけど
FATが固定テーブルのままだから空き領域ビットマップも固定テーブルで良かったと思う
あとFATエントリが32bitのままだから16TB超えると影響出始める
リムーバブルで16TBは当分先とは言え将来はわからないぞ
713:login:Penguin
19/08/30 01:41:03.03 49Usa2R4.net
MSがさっそく公式に公開してたじゃないか
URLﾘﾝｸ(docs.microsoft.com)
714:login:Penguin
19/08/30 04:24:29.13 itEjT5Wb.net
>>700
> あとFATエントリが32bitのままだから16TB超えると影響出始める
exFATの理論上の最大ボリ�