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の理論上の最大ボリ�
715:�ームサイズは128PB（ペタバイト）だよ 128 * 1024TB = 131,072 TB。実装上の問題で 512TBが推奨とされてるけど https://en.wikipedia.org/wiki/ExFAT
716:login:Penguin
19/08/30 04:38:30.70 itEjT5Wb.net
なるほど、FAT32は名前に反してクラスタ数として28bitしか使ってなかったのか。（exFATは32bit）
1クラスタのサイズがFAT32は32KBまでだから、FAT32の理論上のボリュームサイズは8TB
exFATでは32bit全部を使うから、これだけでも128TBまで使えることになるが、
さらに1クラスタの最大サイズが32KBから32MBに増えたから、理論上のボリュームサイズは128PBになるんだな
FAT32もexFATも実際の実装はそこまで対応してないから減るわけだけど
将来的に対応の必要性があれば互換性を保ったまま増やせるわけか
717:login:Penguin
19/08/30 11:49:45.26 xVO3b390.net
>>691
btrfsなんて不安定で微妙なFSじゃなくってext4とかXFSで瓦対応してクレヨン……
と思ったが瓦はCoW向きなのか
だったら仕方ないかorz
718:login:Penguin
19/08/30 18:29:14.36 BfSogZjl.net
マジかよ今後はexfat一択じゃん
719:login:Penguin
19/08/30 19:36:46.24 wK/ekzyO.net
でもexfatってジャーナリングファイルシステムじゃ無いんでしょ
720:login:Penguin
19/08/30 20:17:53.57 BfSogZjl.net
マジかよじゃあexfat要らね
721:login:Penguin
19/08/30 21:52:37.76 xOfxtSvx.net
やっぱりntfsが最強だな
722:login:Penguin
19/08/30 22:33:18.67 lt7x2d9b.net
>>704
xfsはSMR対応やる気あるだろ
723:login:Penguin
19/08/31 01:01:49.85 PjcUVRL7.net
xfsのCoWがどんな感じかだな
btrfsはCoWだけじゃなくパケットライトのような構造でSSDへの負担の軽減と効率化を図っている
副作用でデータベースのようなランダム書き換えを繰り返す用途と非常に相性悪いけどな
724:login:Penguin
19/08/31 07:09:26.49 R786WVAl.net
>>706
> でもexfatってジャーナリングファイルシステムじゃ無いんでしょ
ジャーナル対応は可能だよ。
725:login:Penguin
19/08/31 09:11:35.30 PjcUVRL7.net
可能なのと実装しているのは大きく違う
ext2にジャーナルファイルを追加してext3としたように後付ならどうにでもなるが
それでも名前を変えるレベルの変更になる
互換性が重要なリムーバブル向けで大きな変更はできないだろうな
exFATは冒険を避けたのか内部的にはけっこう中途半端な拡張になっている
726:login:Penguin
19/08/31 11:53:17.85 M9ADFjBr.net
ディレクトリエントリ構造がvfat引き継いでんのがクソ
727:login:Penguin
19/08/31 12:43:47.93 KGfTBrB+.net
kwsk
728:login:Penguin
19/08/31 14:12:33.52 JnSDyXRZ.net
kwskっていうのはクソの理由だぞ。
vfat引き継いでるということの説明をされても
クソの理由にはならないからな
ってかvfat引き継いでないがなｗ
729:login:Penguin
19/09/03 17:02:34.99 yL/ahKNe.net
Linuxに関して言えば，
組込みLinuxが入ってる携帯端末とかはexFATを採用しそう。
そうじゃないのはXFSやext4でいい(「でいい」というか，「が十分使える計算機資源がある」
730:login:Penguin
19/09/03 17:44:40.69 xfgJCc5v.net
exFATを使うというのが単に外部ストレージのファイルシステムとして受け付ける(マウントして読み書きに対応できる)という話なら対応が進むだろうが、
システムやユーザーディレクトリがexFAT上に置かれるようになる、システムパーティションとしてexFATが採用されるという話なら、それは無いんじゃないの？
システムパーティションとしてFATやexFATを利用可能な実装、あるならそれがデフォルトの実装というものが実在するなら、むしろ見てみたい(提示して欲しい)。
パーミッションなにそれという無法の罷り通る組み込み実装というものが実在するなら恐ろしい話だ。
NTFSならUNIXの(POSIXの)パーミッション機能を全て内包した上でより高度かつ緻密な権限設定なども可能だが、それらの機能をUNIXからは満足に扱えず持ち腐れるしかないし、
NTFSをシステムパーティションとして設定可能なディストリというものも記憶に無い(Windowsとの共存を念頭に既存のNTFSパーティション内に構築されるものならあったが)
731:login:Penguin
19/09/03 19:05:09.69 B9+IOgvJ.net
Androidではf2fsとext4が使われているな
これは端末によって分かれる
それとユーザー領域にsdcardFSとか言うのが使われている
732:login:Penguin
19/09/03 19:52:16.19 8FoKpEbS.net
>>717
今北産業
733:login:Penguin
19/09/03 20:37:54.95 2aAU5+p7.net
>>717
今でも使えるか知らないけどUMSDOSというFAT用の拡張があるよ
仕組みはVFATのような感じで長いファイル名とパーミッション等を使える
いにしえの文書
URLﾘﾝｸ(archive.linux.or.jp)
それとNTFSのACLと同等の機能はXFS等でも使えるようになっているよ
734:login:Penguin
19/09/03 20:56:32.09 2aAU5+p7.net
>>717
ACL関係もいにしえの文書だけど
URLﾘﾝｸ(www.itmedia.co.jp)
POSIX ACLはSamba以外では積極的に使われない機能だから
あまり解説されていないだけ
735:login:Penguin
19/09/04 01:58:46.87 AfE9OQrQ.net
>>721
NTFSと同等なのはPOSIX ACLじゃなくてNFSv4 ACLとか、HFSやAPFSに実装されている方
736:login:Penguin
19/09/09 22:59:51.66 SszYAJmS.net
互換性は別にして、機能としてPOSIX ACLになくて、NTFSやNFSv4 ACLにある物って何があるの？
デフォルト値とかが違ってWindowsと全く同じ挙動にはできないけど、機能的には同等だと思ってた。
737:login:Penguin
19/09/10 02:47:59.60 7v2JkFhP.net
>>723
POSIX ACLはパーミッションの素直な拡張で、
・ユーザーやグループ毎にRWXの3種類の許可のオンオフ
・ディレクトリにデフォルト値を設定して子孫に継承させる
だけ。
NTFSの方は、そもそも権限が13種類ぐらいあって複雑怪奇。例えば、
・属性(タイムスタンプとか)の読み込みだけ許可
・ファイルへの追記だけ許可(上書きは不可)
・ファイルは作れるけどサブディレクトリは作れないディレクトリの実現
・ファイルの削除権限をファイル自体に設定
・ファイルを作れるけど消せないディレクトリの実現
・ACL自体の変更権限や所有者の変更権限を設定
などが可能。継承も、
・ファイルとディレクトリで別々に設定
・子には継承させるが孫には継承させない設定
ができる。更に
・許可/拒否の設定が両方ある
・ACLの適用順を明示的に設定できる
ので、ホワイトリスト式とブラックリスト式を複雑に組み合わせられる(これはGUIでは設定不可で、コマンドでやる)
738:723
19/09/10 03:14:54.16 ux9dqJdd.net
>>724
おお。確かに全然違う。NTFSそんなに機能あったのか。
勉強になった。ありがとう。
739:login:Penguin
19/09/10 04:08:11.19 QHsS5imR.net
機能的にはミニコンやメインフレームで大規模なDB載せるような用途にも対応できるような作りだしねえ…
これでもう20年も実績あるんだから、いっぱしのファイルシステムですな >NTFS
740:login:Penguin
19/09/10 04:31:51.09 c/QawrHU.net
そのNTFSの機能はだいたいZFSで網羅してるな
741:login:Penguin
19/09/10 05:23:00.38 h9c2d3nY.net
ZFSで網羅してるとして、何のコマンドでやるの？
ZFS専用コマンド？
742:login:Penguin
19/09/10 06:24:47.98 hXcE461p.net
ZFSってIRIX発祥だったように記憶しているのだけど
IRIXはつまり一般的なPOSIXの枠を超えたACLを独自に実装していたということですかね？
743:login:Penguin
19/09/10 06:35:34.93 c/QawrHU.net
>>728
意外なchmodで全部
744:行ける。まるで呪文だがw setfacl -m owner@:full_set:allow,group@::allow,everyone@::allow acl_test.txt https://docs.oracle.com/cd/E24845_01/html/819-6260/gbacb.html#scrolltoc >>729 Solarisでそ？
745:login:Penguin
19/09/10 06:41:05.19 c/QawrHU.net
>>730
自己レス
ごめん
chmod A3=user:venkman:read_acl:allow filename はSolaris
freebsd はsetfaclでやる実装だった「
746:login:Penguin
19/09/10 13:55:09.50 6sIzNa2X.net
> 729
XFSはIRIX
ZFSはSolarisです。
747:login:Penguin
19/09/10 15:10:51.24 TIJq+nNn.net
ext4でいいじゃん
748:login:Penguin
19/09/10 16:55:49.82 +5M9tkhk.net
>>724
詳しい解説サンクス！
多すぎて頭がフットーしそうだよお
749:login:Penguin
19/09/10 16:56:33.60 +5M9tkhk.net
>>730,731
こっちも詳しい解説サンクス！
750:login:Penguin
19/09/10 19:00:28.68 nfLMQN5s.net
>>732
ああそうだ、IRIXはXFSだったわごめん
おれ個人では普通に信頼してるFSだけど、Linux界隈では個人だと使ってる人あまり見ないよね…
751:login:Penguin
19/09/11 01:29:58.78 U4ts0n/J.net
LinkStationのデフォルトがXFSだったはずたから知らないうちにXFS使ってる人は案外いそう
752:login:Penguin
19/09/11 02:15:06.94 XGTr0XqS.net
CentOS7のデフォルトがXFSだから、個人でも使っている人は沢山いるはず
753:login:Penguin
19/09/11 09:22:32.33 Im0aUzbI.net
NTFSってマジで「多」機能なんだな
754:login:Penguin
19/09/11 20:34:04.82 U4ts0n/J.net
多機能すぎてその詳細を理解してる人も使いこなせる人も少ない…MSにさえ
おまけにフルに機能使いこなそうと思ったら非公開API使わなきゃいけないとかいう残念さ
755:login:Penguin
19/09/11 22:52:50.67 Im0aUzbI.net
URLﾘﾝｸ(m.facebook.com)
これを思い出した
756:login:Penguin
19/09/12 08:02:48.44 A7RqdNx4.net
素直にXFS使っとけ
757:login:Penguin
19/09/12 14:07:40.59 kpioEvUr.net
XFSは多機能すぎて誰も使いこなせない
758:login:Penguin
19/09/13 10:02:05.12 /kG8R/3p.net
LinuxのXFSにもGRIOあるのかなぁ
759:login:Penguin
19/09/15 08:26:10.55 A0tbtNjH.net
EROFSがLinux5.4でメインライン入りするらしい
リードオンリーファイルシステムだから使いどころは限られるが
すでにスマホで動いているので実績はある
760:login:Penguin
19/09/15 09:51:04.18 uMzOqD6G.net
え、エロFS……
761:login:Penguin
19/09/15 13:31:08.77 ua5r3kDz.net
エッチFS!
762:login:Penguin
19/09/15 17:37:09.38 3/04JcE1.net
>>743
何で圧縮は無いの？
763:login:Penguin
19/09/16 01:54:38.69 rJPiMVYE.net
huawaiのスマホのsystemパーティションでEROFS使われてるのか
androidのsystemは元々リードオンリーでマウントされてたから有用だろうな
764:login:Penguin
19/09/16 21:49:59.06 8Mnz6MjR.net
くだらない質問で恐縮なのだが、
既存の、RW可能なファイルシステムで作成したボリュームをROでマウントするのはわかる。
しかしリードオンリーのファイルシステムとなると、
マウントするボリュームは、一体どのような手段で作成されるのだろうか？
卵が先か、鶏が先か…
765:login:Penguin
19/09/16 22:16:57.15 Fjxy1taP.net
>>750
.iso (ISO9660 ファイルシステム、DVD-ROM 等に使われるリードオンリーのファイルシステム)
ファイル作ったことないですかそうですか
766:login:Penguin
19/09/16 22:20:45.35 M+XuPW8F.net
>>750
別のファイルシステムから変換するのでは？
少なくともISO9660はそういう感じだよね。
原理的に、仕様がわかっていて、どう�
767:｢う風にファイルを用意したいか決まっていれば、 ビット列は生成可能なのだから、鶏が先か、卵が先かという問題ではないような気がするけど。
768:login:Penguin
19/09/16 22:23:33.54 v2xaK5dV.net
erofs-utilsに入っているmkfs.erofsで作るらしい
URLﾘﾝｸ(git.kernel.org)
769:login:Penguin
19/09/17 00:23:24.54 tEkIjiM2.net
>>750
いや、roなファイルシステムも使用時にroでマウントしてるだけで
作成時はイメージファイル上にFSを作ってrwマウントしてファイルコピーするだけ
770:login:Penguin
19/09/17 02:01:04.20 C2z//eYW.net
>>753
圧縮の有無に違いはあるけど、使い方はSquashFSみたいな感じらしい
771:login:Penguin
19/09/17 09:41:47.16 mAQfPWIi.net
>>754
なるほど，まあ当然っちゃ当然そうだよな。
772:login:Penguin
19/09/17 12:22:17.37 8KO1t32N.net
>>754
isofsはwrite()が実装されてないらしいし、rwマウントしてコピーってのはちょっと違うのでは？
773:login:Penguin
19/09/17 21:24:20.70 2Wuln3eF.net
fuseとかでrwマウント出来るようにした物はあるだろうけど、最初からrwでマウント出来たらroファイルシステムじゃないだろｗ
774:login:Penguin
19/09/17 22:27:12.02 q0qVtnVz.net
ro専用のファイルシステムって、誰が書き込むの？
775:login:Penguin
19/09/17 22:50:56.62 uhDzaob2.net
mkfsが｢XXバイト目にマジックナンバー書き込んでYYバイト目にはこのフラグの値書き込んで｣みたいにやってる時に一緒にファイルも書き込むだけ
776:login:Penguin
19/09/21 04:11:32.07 H9H9TTsk.net
これでZFSの重複排除が実用的になるだろうか？
まともに使えそうなら革命的だが
URLﾘﾝｸ(www.phoronix.com)
777:login:Penguin
19/09/21 23:27:31.72 bKqCk4Ie.net
重複排除なんてバックグラウンドでやればいいだけじゃないの？
778:login:Penguin
19/09/22 05:53:45.18 CqaW/Zfz.net
今時のバックアップソフトや専用NASはリアルタイムに重複排除出来る
779:login:Penguin
19/09/30 15:09:29.89 /fxpH8Tk.net
>>762
重複するデータが既にストレージ上に存在するのなら後続の書き込みは行われないのが理想
780:login:Penguin
19/10/01 01:58:35.48 xLonTYnk.net
>>764
コピーするときだけで十分だろ
どうせ上書きしたら内容は変わるんだし
781:login:Penguin
19/10/01 02:38:11.33 C0EfQGgt.net
重複データは書き込み時に判定というのは実際どう判定するのか
書き込み前に一度ファイルを舐めて双方のハッシュでも比較するのか、すごい手間だな
そんなものシステムワイドでファイル作成時や最終書き込みの時にハッシュ引いてファイルの属性データの方に持たせておけばいいのに
それでもハッシュの衝突とか無いとも限らないしな…どうやって検出すればいいんだ
…などと考え始めると眠れなくなる
782:login:Penguin
19/10/01 03:54:30.13 O/YTzUB3.net
うん、だからバックアップでやればいいんじゃねーのって思ってる
最終的にはファームウェア側で実装するのもありかもね
783:login:Penguin
19/10/01 04:01:48.13 O/YTzUB3.net
>>766
ファイルレベルでハッシュ比較しても駄目だよ。
少しデータが変わっただけの巨大なファイルで重複排除ができなくなる。
でもまあそういう例って仮想イメージのスナップショットぐらいしか無いんだよねｗ
んで、仮想イメージは仮想マシン側がスナップショットを差分で保存してくれるから関係ない
ファイルレベルならバックグラウンドでファイル検索して
ファイルサイズが同じ→中身を比較→全部一緒ならハードリンクにする
これだけで十分だろう
784:login:Penguin
19/10/01 04:34:23.91 LD5IBfg0.net
ログファイルとか重複排除すると効果大きいんだけど
785:な 一般家庭の用途だとストレージのほとんどがメディアファイルで埋まるから効果薄いよね
786:login:Penguin
19/10/01 08:13:43.35 O/YTzUB3.net
>>769
なんで同じ内容のログファイルが
大量にできるんだ？
圧縮ならまだしも何の意味もないだろ
787:login:Penguin
19/10/01 08:17:03.18 O/YTzUB3.net
Windowsは95の時代からドライブの圧縮機能があって
昔はお世話になったもんだが、他のファイルシステムには
そういう機能あるのかな？
788:login:Penguin
19/10/01 10:03:19.94 oU66RV/q.net
>>770
そもそもファイル単位という前提が間違ってる
789:login:Penguin
19/10/01 10:26:58.35 mUwF5icW.net
>>772
ブロック単位とか言いたいんだろうが、何単位であっても
ログファイルなんて同じ内容にはまずならんだろうが
1バイト違っていたりアドレスがずれてるだけでも
だけでも違うものと判断されるんだからさ
790:login:Penguin
19/10/01 22:11:05.16 d4igWScA.net
ZFS とか重複排除はかなりメモリ食うらしいね
NTFS は指定日数経過後のファイルに対してだけ実行するとか
バックグラウンドで実行/高負荷時には実行しないとか
使用メモリ制限とか色々オプションがあるみたい
モードも一般/VDI/バックアップと用途向けに用意されてる
中小規模、ホームユースで考えると NTFS の方式はわかりやすくて
かつ優秀だと思う
791:login:Penguin
19/10/01 22:33:23.76 acLZahM8.net
確かNTFSの重複排除は対象ディスク領域1TiBあたり1GiBのメモリを確保することが推奨されていて、
これはZFSでの重複排除使用時の推奨値と変わらないはずですよ。
重複排除での処理単位のブロックサイズが同じ程度なら、
管理情報のオーバーヘッドはそれほど変わらんでしょう。
792:login:Penguin
19/10/01 22:34:34.00 acLZahM8.net
あ、推奨値じゃなくてこれぐらい消費しますよの目安だったかも。
793:login:Penguin
19/10/01 23:59:37.95 d4igWScA.net
>>775
メモリ使いすぎないオプションもあるよって書いたんだが...
794:login:Penguin
19/10/02 10:24:24.64 MFUU2o8w.net
NTFSって複雑奇怪な仕様のくせにムダに安定してるよな
795:login:Penguin
19/10/02 20:38:07.52 gqMjbdgw.net
NTFSの重複除去処理って理想的な実装じゃね？
URLﾘﾝｸ(www.gmo.jp)
> 重複除去機能はWindows Server2012ですでに搭載されていましたが、
> 最新のWindows Server 2019の重複除去では、重複除去率とパフォーマンスが改善されており、
> ファイル単位ではなくバイナリのデータ単位で重複を検出して除去するため、
> 大幅に重複除去率が向上しています。
> 重複除去は一度設定すればボリューム内のすべてのファイルが対象となり、定期的に実行されます。
> 書き込みごとに圧縮される場合、継続的なパフォーマンスの懸念がありますが、
> 重複除去はスケジュール設定が可能なため、慢性的なパフォーマンスへの影響を回避することができます。
796:login:Penguin
19/10/03 00:59:58.79 OEBySPhx.net
NTFSは本当に優秀だ
NT3.1の頃から業務で使っているが、FS起因でのトラブルには一度も遭遇したことがない
さすが天才カトラーが設計しただけある
797:login:Penguin
19/10/03 02:03:54.40 7cVKYu14.net
MSの開発者のスキルは世界一だからね
本当凄いよ
798:login:Penguin
19/10/03 08:52:36.44 tzg7uxom.net
優秀つっても Isilon や NetApp とかの後追いじゃないか？
OneFS, WAFL, NTFS 以外は完全において行かれた感がある。
zfs や btrfs はそれなりに資金力ある企業傘下だったが残念だ。
799:login:Penguin
19/10/03 0
800:8:52:50.20 ID:47VJX03k.net
801:login:Penguin
19/10/03 15:39:46.94 06JgUDhC.net
zfsはSunがあんなことにならなければ…
802:login:Penguin
19/10/05 20:56:50.83 6SloAFsk.net
NTFSの仕様はマジで謎。
803:login:Penguin
19/10/22 03:48:30 sLMeSFJA.net
Ubuntu 19.10でZFSをルートファイルシステム利用やっとかよ
804:login:Penguin
19/10/22 04:05:31 sWREnU7X.net
ルートにzfs使うことある？
805:login:Penguin
19/10/22 16:37:32.09 bJW2ueVJ.net
zfs重くて泣いた
806:login:Penguin
19/10/22 23:17:46.10 4WVgaPY2.net
zfs raid-1
807:login:Penguin
19/10/24 07:14:24.88 e5plJI2y.net
ZFSの優秀さはメモリと引き換えなのでパソコンクラスのメモリ量だとあまり使えない
808:login:Penguin
19/10/24 14:36:52.38 87akmZa+.net
パソコンクラスってよく分からない表現だな
今のサーバーはほとんどPCサーバーになってきてるのに
809:login:Penguin
19/10/24 15:34:41.99 V0q9EpU/.net
パーソナルなやつだろ
810:login:Penguin
19/10/24 19:01:35.46 XtN2MzoY.net
ZFS出た2005年当時のメモリなんてどれだけだったと思ってるんだ
811:login:Penguin
19/10/25 09:09:25.10 Krt8XDYr.net
うちのパソコンはメモリ512GBだけど足りないかな？
812:login:Penguin
19/10/25 09:54:42.46 dtRwUszk.net
OpenZFSはメモリ要件が改善されたらしくはあるけど
キャッシュヒットが環境によって変わるとはいえメモリの必要量が明確に分からないのは正直つらい
L2ARCの追加もメモリ消費するらしいから安易にできないし
でもZILとかスナップショットとか透過圧縮とか使いたい
813:login:Penguin
19/10/25 10:31:10.97 fu1VNf4G.net
NASでZFSのdedup onで使ってるけど2TBでメモリ10Gも使わない
メモリ512GB積んでおけば100TBぐらいまでは対応できそうだから個人だとこれで十分そうだ
814:login:Penguin
19/10/25 13:35:51.25 +KpuEA9M.net
重複排除設定で使用済みブロックが2TBも使ってるなら相当ゴツいシステムだな
815:login:Penguin
19/10/25 23:24:59.22 IP6r7udF.net
重複排除ってサイズが1バイトずれてるだけのやつも
排除してくれるの？
816:login:Penguin
19/10/25 23:52:06.19 dtVaeIT3.net
な訳ねー
817:login:Penguin
19/10/25 23:54:37.46 IP6r7udF.net
あんまり排除できなくないか？
同じファイル見つけたらハードリンクに
置き換えるツールで十分そうｗ
818:login:Penguin
19/10/25 23:57:34.59 dtVaeIT3.net
そうだよ、専ら仮想鯖みたいな同じユーザランドが無数に作られる様な用途を想定してるんだろう
819:login:Penguin
19/10/26 01:22:02.81 vQVY0Sjj.net
一日1万枚ぐらいエロ画像を漁ってると20%ぐらいはかつて落としたエロ画像だったりするから
重複排除は容量の20%ぐらい浮く計算になる
820:login:Penguin
19/10/26 01:25:37.95 bm797MDp.net
>>802
そういうのって重複ファイル削除ツール使えばいいだけなんじゃない？
重複させておく必要ないでしょ？
821:login:Penguin
19/10/26 01:29:08.15 Pwsut+Es.net
重複排除はリアルタイムである必要はないわな
ZFSが採用しているようなリアルタイムでの重複排除はメモリを食うし
デスクトップ用途ではデメリットの方が大きい。
XFSの重複排除はパフォーマンスに影響しないし実際に使っているけど便利だよ。
822:login:Penguin
19/10/26 02:04:42.61 /XO9wWRE.net
後で重複を排除するとなると重複かどうかがわからないから結局一度書き込みに行く事になる
zfsはデスクトップ用途だとアレだけどサーバ用途だと理に適ってはいる
あと画像だと今や同じ画像が違うファイル形式であちこちに散乱してたり
同じJPEGでも品質が違ってたりするからあんまし意味ないんじゃ？
823:login:Penguin
19/10/26 02:47:15.22 bm797MDp.net
でも書き込むたびに、これ重複してるかな？って
確認してたら、書き込みが遅くなるじゃん
824:login:Penguin
19/10/26 06:32:43.54 /XO9wWRE.net
それを高速化する為にメモリ内にハッシュの類を持ってるんだろうに
825:login:Penguin
19/10/26 10:45:29.30 ZfJ5IMnc.net
でも書き込むごとに、データのハッシュ値を計算してるんですよね？
826:login:Penguin
19/10/26 11:39:20.84 +7ZIaVI7.net
>>807
非同期書き込みなら書き込み遅いのは気にならないが同期書き込みについては
遅くなるのは致命的だよな
同期・非同期で重複排除をバックグラウンドでやるかリアルタイムでやるか決め
られるだろうけど仮想環境用途の仮想ディスクとかはその上の同期・非同期って
NAS側まで伝わるのかね
>>808
ZFSの場合はハッシュの計算以外にもRAIDの計算もしているが、それをいうなら
商用NASハードはそれで百本越えのHDDとか面倒みながら処理してるわけで
ハッシュ計算はそんなに負担ではないのでは？
827:login:Penguin
19/10/26 11:54:16.15 kG6Y+7fi.net
いやめちゃくちゃ負担だけど
やらなきゃ駄目だから
828:login:Penguin
19/10/27 15:53:27.45 eiS+LtlM.net
>>800
重複排除はファイル単位ではなくブロック単位
もしファイル単位ならそりゃハードリンクと同じだ
829:login:Penguin
19/10/27 17:06:24.41 707D9EX6.net
異なるファイルでブロックが同じってまずないだろ？
830:login:Penguin
19/10/27 23:20:14.99 3lwG/9wl.net
それをファイルレヴェルでやってたらでかいファイルの一部が変更されただけで
ハッシュの類を再度算出しなおさなきゃいけなくなる
831:login:Penguin
19/10/28 00:15:16.75 IKPi8ihE.net
>>812
世代でバックアップとってるファイルとかゲストOSのイメージとか
832:login:Penguin
19/10/28 20:47:04.72 dxvlefLW.net
ファイル単位の重複排除もあるらしい。
更新されなくなったファイルを圧縮するついでにやる？だったかな。
他にもウイルススキャンとかも定期的に走らせるとかあるからハッシュの
再計算を何かのついでにすることで負担は減らせそうだね。
833:login:Penguin
19/10/28 22:31:04.60 9iH4PItu.net
>>814
そういうのって仮想マシンソフト側が対応してますよね？
834:login:Penguin
19/10/28 23:10:44.32 WlwazsDj.net
ファイル単位でやるにしてもどうしても大きさに制限ができる
COWの事を考えるとどうせブロック単位に回帰する
835:login:Penguin
19/10/29 00:52:41.78 fdP/pgCQ.net
>>816
横から失礼
同じ仮想マシンイメージのPCを移動ユーザープロファイルで利用する
ならわかるが、サーバだと初期イメージから離れていくだけだから
差分に対しては仮想マシンソフト側での吸収は難しいと思うが
>>817
データベースの表領域を考えるとそうだけど、それ故最近アクセスしていない
ファイルに限定してるんじゃないかな
そうなると話は変わって逆に大きさがわかる/ファイルサイズがわかるのは
寧ろメリットになってしまう
ブロック単位に回帰する理由を挙げるならスナップショットやシンプロ
ビジョニング、ブロック単位のレプリケーションなど併用すると効率的な
機能要件挙げるべきかな
836:login:Penguin
19/10/29 03:00:41.08 L6q0zJPq.net
自宅のCDデータ倉庫で排除率のシミュレーション'(zdb -S)したけど1%も無くてがっかりだった
やっぱZFSの重複排除は仮想化とセットなんかな
バックアップは取得時だけソフトで差分の処理するほうが安くできそうだし
837:login:Penguin
19/10/29 08:54:54.57 tiBJfX00.net
>>819
zfsは仰る通りだと思う。
コピーオンライトのお陰でスナップショットが高速・少容量な感じに仕上がってる。
838:login:Penguin
19/11/16 21:42:02.73 JSAAagCz.net
重複排除に夢を見ないほうがいいよ
元から圧縮をはじめとする各方面で無駄を無くす努力がなされている現状で
小手先の策は効果がない
839:login:Penguin
19/11/20 20:25:14.01 6yGwAp7b.net
そうか？今日保存したエロ画像は以前見てHDDのどこかに保存したような気がするんだが
840:login:Penguin
19/11/20 20:40:58.51 oxDwVSd5.net
同じ画像に見えてもバイナリ的に同一じゃない要素があってなぁ
というかそういう画像を探すための同一画像判定をしてくれるアプリがあったな
841:login:Penguin
19/11/21 05:47:34.09 FXPGTnmV.net
画像はまだいいけど同一の動画を判定するのは難しそうだなあ
できるソフトあるのだろうか？
842:login:Penguin
19/11/21 09:09:11.59 xIJF9Sc2.net
Googleなら持ってるだろうが
843:login:Penguin
19/11/21 09:58:12.19 qhCu6Ui0.net
おれは一期一会派だから
844:login:Penguin
19/11/21 20:44:46.78 FOikuE8m.net
>>826
年々規制が厳しくなるからいつか後悔するぞ
845:login:Penguin
19/11/23 07:34:28.58 RKp6gT6E.net
すでに御禁制の品です
846:login:Penguin
19/11/26 09:21:12.69 WiM8NUkS.net
>> 826
俺は市毛良枝派だった。
847:login:Penguin
19/11/26 19:19:34.18 dryjMwbD.net
仮想マシンのイメージのように重複排除が効果的なものはあるけど
そういうのは個別に専用の仕組みで対応したほうが早い
例えば掲示板の画像なら重複を探してハードリンクを貼るスクリプトを定期的に回すだけで事足りる
一応btrfsは重複ブロックを探して共有するプログラムが用意されている
さまざまなリスクと制約を負ってでもリアルタイムにファイルシステムでやる必要性が少ない
848:login:Penguin
19/11/26 22:41:02.69 KV/Dsi98.net
>>830
いやそれだったら画像を保存するだけのプール作ってそこだけdupすればいいだけ
849:login:Penguin
19/11/27 01:03:11.01 j6YMclKw.net
URLﾘﾝｸ(www.phoronix.com)
> Linux 5.4 Kernel Released With exFAT Support, Faster Radeon Graphics, New Hardware
exFATｷﾀ━━(ﾟ∀ﾟ)━━!!
850:login:Penguin
19/11/27 01:10:07.14 vV9+H2A1.net
これでexFATが汎用性最強になったね
851:login:Penguin
19/11/27 01:36:26.23 twkxM08i.net
でもジャーナリングファイルシステムじゃないからなぁ
852:login:Penguin
19/11/27 01:39:22.97 BHucuGJr.net
全く用途が違うだろ・・・
何を見当違いな
853:login:Penguin
19/11/27 03:08:57.62 zVRigbnf.net
そう言えばRaiserさんはFS開発に戻らないんだろうか
854:login:Penguin
19/11/27 07:27:41 yuP2HKak.net
そもそもSDXCカードの標準に採用されてるのに読み書きできない方がおかしい
855:login:Penguin
19/11/27 10:28:42.57 aEg54iqa.net
fatは先頭からデータ埋めてくだけだったけどexfatはそのへんどうなの?
856:login:Penguin
19/11/29 08:14:02.98 Vz7mdWod.net
スパースファイルのことなら対応してない
アロケーションのことなら実装次第でFATと変わらんだろう
メタデータの一部がファイル化してるが位置がころころ変わるものじゃないから断片化には影響しない
857:login:Penguin
19/12/03 19:17:30.18 fFA/yNYa.net
Valid Data Length、Linuxで言う所のUnwritten Extentsなら有る
URLﾘﾝｸ(docs.microsoft.com)
858:login:Penguin
202
859:0/01/01(水) 11:10:00.15 ID:scCDRay6.net
860:login:Penguin
20/01/01 12:31:59.53 20dym0cL.net
まじかｗｗｗ まさか復帰するとは思わなかった
861:login:Penguin
20/01/01 21:13:48.67 p37tb7FW.net
キラーFSになるな
862:login:Penguin
20/01/11 02:19:39.98 UAAx1hWz.net
2020年1月10日 Don't use ZFS ―Linus，ZFSをマージしない姿勢をあらためて強調 階戸アキラ
URLﾘﾝｸ(gihyo.jp)
「Don't use ZFS. ―ZFSは使わない。その理由はシンプルだ。ZFSはこれまでずっと，バズワード以上の
何物でもなく，そして実感するのだけど，例のライセンシング問題は僕にとってZFSを価値のない存在と
思わせるだけだ」
1月6日，IT業界に特化したオンラインメディア「Real World Tech」のフォーラムで繰り広げられたある
スレッドにて，Linus TorvaldsはZFSをメインラインにマージする予定がないことをあらためて明確に主張
している。(中略)
今後のZFSの扱いについては「Oracleの正式なリーガル担当者が署名したオフィシャルレターが届くか，
もしくはラリー・エリソン自身が“ああ，いいよ，手続きを進めよう”といってZFSをGPLにするか，そういう
事態でも起こらないかぎり，僕はZFSに関するいかなる成果もマージしない」と強調，つづけて「ZFSの
コードやインタフェースを取り入れたければ，個々の環境（ディストリビューションなど）で好きにやるのは
かまわないが，訴訟好きなOracleの体質，さらにはライセンスに関する数々の疑念を考慮するなら，僕は
とても安心してそれをやる気にはなれない」とZFSをメインラインに取り入れない理由を説明している。
また，ZFSを直接カーネルに統合しないだけでなく，Shimレイヤのような透過的なインタフェースを通した
実装にも「まったく興味がない。我々にとってなんの価値もなく，Oracleに（Javaのような）コピーライト
訴訟のよいきっかけを与えるだけ」と一刀両断している。
旧Sun Microsystems由来のファイルシステム技術であるZFSに関しては，何度となくLinuxカーネルでの
実装が議論された過去があり，たとえばUbuntuでは2016年ごろからZFSをサポート，最新版の「Ubuntu
19.10」ではZFSをrootファイルシステムにしたインストールが可能となっている。Linusはこうしたディストリ
ビュータの動きに関しては「やらないほうがいいと思うけど，自分たちの責任でやるなら好きにやれば」という
スタイルを通してきたが，今回あらためてZFSのメインライン統合に対し，明確なNoを突きつけたといえる。
863:login:Penguin
20/01/11 04:42:55.15 jnlXzU71.net
マージ無いのはまあ当然だろう
ZFSの為だけに
864:全てのコードをリスクに晒すわけにはいかない
865:login:Penguin
20/01/11 13:42:21.31 6TxpLfrk.net
枯れたjfsで運用しとる奴居らんの？
866:login:Penguin
20/01/11 13:44:36.61 6TxpLfrk.net
LinuxはSiliconGraphics謹製のxfsと添い遂げろ
867:login:Penguin
20/01/11 14:05:29.73 +MC8qtlu.net
jfs いいぞ。
と、言いたいけどAIX由来じゃなくてOS/2からだし
868:login:Penguin
20/01/11 16:12:02.81 ICeSTzlT.net
OS/2ってHPFSじゃないの？
869:login:Penguin
20/01/11 18:40:44.21 K/LCgiW1.net
>>847
どうせならReiserFSがいいな
870:login:Penguin
20/01/11 18:57:24.78 FZkUfr0E.net
>>849
wikipedia の jfs からだが、
1999年4月、新しい JFS が OS/2 Warp Server for e-business に、2000年10月には OS/2 Warp クライアントに向けてリリースされた。
1999年12月、OS/2 の JFS ソースコードがオープンソースコミュニティに提供され、それを受け JFS の Linux への移植が始まった。2001年6月、JFS for Linux の最初の安定版がリリースされた。
871:login:Penguin
20/01/11 19:17:27.72 ptgZv5Qn.net
JFSはビデオレコーダーとかのHDDのフォーマットに使われている場合が結構ある/あったか
今はXFSとかか？
872:login:Penguin
20/01/13 11:25:23.35 mGzs+Xmt.net
>>852
むしろレコーダーにはXFSが使われてるイメージ
873:login:Penguin
20/01/14 04:51:06.14 iZnsu89D.net
うちにちょっと古めのRegza(TV)が2台があるが、録画HDDが認識されなくなって
xfs_repairで3回くらい復活させたことがあるわ
874:login:Penguin
20/01/14 08:15:51.05 bK6lhlF1.net
ZFS厨死亡のお知らせ
URLﾘﾝｸ(www.phoronix.com)
875:login:Penguin
20/01/14 08:55:56.23 U+JHY6EW.net
典型的な老害
876:login:Penguin
20/01/14 09:01:27.05 /3xc9qkj.net
じゃあbtrfs使いますかって話よ
俺はトラウマあるから無理
877:login:Penguin
20/01/14 09:36:14.17 Tzu77Qmb.net
>>855
今までと変えるつもりはないからこれ以上話を出すな、ってだけだと思うんだけど
RedHatがxfsベースで似た機能を持ったもの作るのと、ReiserFSがそこまで取り込んでくれるのを期待
878:login:Penguin
20/01/14 10:05:18.06 3ySwGeCo.net
>>856
法的な問題が解決されない関わらないっていうのを改めて明確にしただけだと思うけど
879:login:Penguin
20/01/14 11:40:03.53 kTd0knbb.net
ZFSなんかバズワードだって一刀両断は胸がすくね
Macが採用を謳ってからの持ち上げようったらおかしかった
880:login:Penguin
20/01/14 12:03:54.46 Co6d2U6R.net
linuxではバズワードかもしれないけれど、
FreeBSDなんかは、UFSの代替として一般化してると思うよ。
881:login:Penguin
20/01/14 14:46:05.21 s3yt3V1I.net
ソースも見ないアホが語っとるわ
リーナスが言ってるZFSはOracleのZFSのことであってOpenZFSではないぞ
882:login:Penguin
20/01/14 17:03:51.82 QOKr6lO9.net
xfsが進化しまくってるから問題ない
俺も早速1年くらいxfsのcowで使っているけど
btrfsとは違ってド安定で一切不具合はないよ
ただしメモリの使用量はなんか多い気がする
883:login:Penguin
20/01/14 17:24:05.89 vHb4j94C.net
>>863
xfsは昔からメモリ大好きっ子やけんな
884:login:Penguin
20/01/14 17:26:23.56 t+wcCOjj.net
スナップショットと圧縮が欲しいんだよー
885:login:Penguin
20/01/14 17:29:22.78 J8UtrzpS.net
>>862
ライセンスがGPLにならないかぎりは同じこと
886:login:Penguin
20/01/14 17:38:02.82 3ySwGeCo.net
>>862
誰にアホといってるのか分からんけど
OpenZFSだろうがライセンスが変わらない限り一緒だといってるだろ
887:login:Penguin
20/01/21 20:00:20.75 ugNUCPRp.net
たとえGPLになって取り込まれたとしてもZFSに使いどころがないわ
ガリガリ読み書きする部分にはメタデータアクセス遅すぎて使えん
ガチ性能と可用性が必要なところはハードウェアRAID組む
ニアライン用なら機能いらんからもっと安定してるやつ使う
888:915
20/01/21 22:45:23 iC7ldWE7.net
LinuxはZFS並みのファイルシステムができるまでまだまだかかりそうね
889:login:Penguin
20/01/22 00:52:27.43 RmlHZiYt.net
超サーバ用途には使わんし、かと言って一般的なPCじゃ必要メモリが大き過ぎて使えんし、
運用のハードルが高い割には使いどころが難しいのよね
890:915
20/01/22 00:59:56.25 97fPzXLY.net
使ったことないんじゃない？メモリ2GBでも快適だよ
今時のマシンなら16-32G積んでるしちゃんと使ってみてから評価すればいい
891:login:Penguin
20/01/22 01:20:43 sJWFkN+Y.net
2GBで快適に動くような使い方してるならZFSでなくてもいいのではって思うけどな
892:login:Penguin
20/01/22 01:58:33 wZeNZHAR.net
メタデータ触ると遅いしメモリ食いなのは確かだけどlvmでスナップショットはかなり無理矢理感あるし透過圧縮ないファイルシステムも多い
893:login:Penguin
20/01/22 07:16:30 97fPzXLY.net
snapshot、promote、細かいACL、send|reciveに透過圧縮など非RAIDでも恩恵はでかいよな
894:login:Penguin
20/01/22 11:38:59 sjf0Rz/o.net
>>874
だね
俺はデスクトップユーザーだからそれら機能の簡易版でもあればbtrでもxfsでも構わないのだが
現時点では選択肢がzfsしかない
895:login:Penguin
20/01/22 16:00:37 vGgGBPjr.net
うんうんZFSは素晴らしいみたいだからFreeBSDでつかっててね
896:login:Penguin
20/01/23 01:55:54.94 7qSP8O0Q.net
FreeBSDもOpenZFSになるのでLinuxで使いますね
897:login:Penguin
20/01/23 14:10:17.07 ZAgXInmL.net
有料でも良ければGPFSが最強なんだけどねえ
898:login:Penguin
20/01/23 14:14:08.14 ZAgXInmL.net
今時は1デバイスで100TB、トータル1PBぐらいのシステムを持っている個人も普通にあるよね
そういうとこで実運用に耐えるファイルシステム、って観点だとこれが以外と難しい
899:login:Penguin
20/01/23 23:53:42.57 6UDxr1tc.net
NTFS
900:login:Penguin
20/01/24 18:35:07 mXgeSarq.net
巨大パーティションは下手すればエラーチェックもままならなくなるから
動画用でもない限り1T程度で切ることにしている
901:login:Penguin
20/01/25 04:40:01 hgworRLd.net
重複排除の実装によくハッシュが使われるがハッシュの計算と保存のコストが馬鹿にならない
例えばKSMは最初ハッシュで実装してたのに結局ツリーを作った上で直接比較する方法に変更した
902:login:Penguin
20/01/25 06:07:36 v2Q4em8k.net
NTFSって理論上は64ビットの番地だけど
現在の実装は32ビットなんだろ
(2^32-1)*2048KiBの8PiBくらいしか管理できない
903:login:Penguin
20/01/25 06:30:47 RUYaEyw5.net
そんな容量が要求される様な用途だとReFSが使われるんじゃ？
904:login:Penguin
20/01/25 07:53:48 TTbJFqbp.net
ファイルシステム上には64ビットで書かれてるよ、
読み書きするときに上位の32ビットを0に固定してるだけ。
たしか、4KBクラスタまでの時代で論理限界16EBとか言ってた。
今は2MBだから増えてる？
905:login:Penguin
20/01/25 10:14:39 9dDjJPoq.net
個人だとだいたい100TBもあれば足りるからな
906:login:Penguin
20/01/25 13:29:15 FQlZOJvl.net
まあストレージやメモリのこれだけあれば十分なんて数字は数年で倍になるし10年で2桁変わる
907:login:Penguin
20/01/25 15:54:16.50
908:Pn3gpz30.net
909:login:Penguin
20/01/25 16:15:25.18 XUbXy/+j.net
10年前でメモリ80MBとかPentium IIを10年使っていらしたんですか？
910:login:Penguin
20/01/25 17:43:01 FQlZOJvl.net
10年前だとメイン機のRAMは8GB、サブ機で2GBだったかな
今はメインで64GBサブ機8GBだから、まあ10倍にはなっていないか
ストレージは1TB→20TB
さらに10年前、2000年時点だとRAM256MBストレージ4GB
1990年頃だとRAM4MBストレージ80MBくらいか
10年で10倍、25年で1000倍目安くらいだな
911:login:Penguin
20/01/25 20:54:00 9YpFJvCS.net
>>888
そこまでいくと実質的に青天井だからS3などのクラウドを選択するだろう
もう自前でストレージを持つ時代じゃない
912:login:Penguin
20/01/26 10:26:40 AHO9IC4m.net
>>888
資源系を筆頭にいくつかの業界や世界規模の大手企業ではPBなんて珍しくないよ
そういうところでは単一ネームスペースでアクセスできるところに意味があるからそうなる
>>891
むしろ逆、そこまで大きくなるとクラウドストレージはI/Oが高すぎて話にならなくなる
913:login:Penguin
20/01/26 11:00:01 OzJ+Z2xw.net
>>892
事業の性質によるだろう
多くのBtoCビジネスでは、必要なストレージ容量やIOはユーザー数に比例するから問題ない
それで赤字ならそもそも商売として成立しない
914:login:Penguin
20/01/26 11:21:19 kSy9PDTE.net
>>892
PBクラスのシステムのファイルシステムは実際は Lustre や GPFS
などの分散ファイルシステムで、その中身は ext4 などのファイル
システムを並列に並べたものだから、単一のファイルシステムとしては
PB 超えれてない
ここでの議論は単一のファイルシステムに限定したほうがいいと
思うんだがどうだろう
915:login:Penguin
20/01/26 11:44:24 kSy9PDTE.net
>>893
> 事業の性質によるだろう
具体的にはスパコン(HPC)と映像系だけかな
CIFS/NFS(autofs)/オブジェクトストレージあたりは複数のストレージを
束ねて１つのネームスペースに見せかけられるからそこそこ安定してて
こなれた価格のストレージを並べるから PB のファイルシステムは不要
テキトーなこと言うけど、PB クラスのファイルシステムが必要になる
のは１ファイルがTB超えるとか１バッチあたりの中間ファイルがTB超える
とかぐらいからじゃないかな
916:login:Penguin
20/01/26 11:53:39 AHO9IC4m.net
>>894
LustreもGPFSもPanFSも中身は独自でext4等の下層fsを持たないよ、何か別のものと勘違いしてない？
917:login:Penguin
20/01/26 12:22:35 AHO9IC4m.net
>>895
HPCはそうだけど映像系は実は必ずしも該当しない、ガチなとこは階層化ファイルシステム使うから
日本では技術力がないのか金があるのか知らないけど単一でゴリ押す映像系の話きくけどね
PB越え単一ファイルシステムが必要なのは、一ファイルの大きさが問題じゃなくて
アクセスする可能性があるファイルが大量にあって、かつテープでは遅すぎる場合
だから金融系・資源系・生命系みたいにデータが大量で時間が金に直結するところで良く使われる
918:login:Penguin
20/01/26 12:26:01 AHO9IC4m.net
>>896
おっとすまない、Lustreは下層がext4だった、ごめん勘違いしてたのは俺だった
でもGPFSやPanFSが下層を持たないのは本当
まあ現状エンタープライズのファイルシステムの最前線はGPFS vs PanFSみたいな雰囲気はある
919:login:Penguin
20/01/26 13:52:42.43 kSy9PDTE.net
>>897
それは失礼。 ちなみに Lustre は ext4 と他に ZFS の実装もあるそうな。
> アクセスする可能性があるファイルが大量にあって、かつテープでは遅すぎる場合
使ってる業種と使い方に異論はないんだけど単一ファイルシステムを使う理由が
920: それかというとちょっとなんか釈然としないなぁ 結局入力ファイルや中間ファイルを複数のファイルサーバに負荷分散するように組むのが 面倒くさいから使ってるってだけって印象だわ 面倒くさがらなった結果の一つが Hadoop/HDFS だと思ってます、ハイ
921:login:Penguin
20/01/26 14:09:39.49 aLHVJ+JL.net
1ファイル1'PBのエロ動画とかどうやって保存してるんだろう
922:login:Penguin
20/01/27 01:02:02 SjNVe4Yy.net
>>900
Display Portが2.7Gb/s最大なんで少なく見積もっても823時間分あるんだが
どういう人向けなのか説明Plz
923:login:Penguin
20/01/27 12:29:14 0w7PQcpt.net
>>901
DPは最大25Gbps出るしDSC使えばもっといける
そもそもファイルサイズとモニターへの転送速度は関係ないでしょ？
実際に販売する段階になったらエンコードして小さくするとしても編集前のマスターデータをそのまま保存しておく場合なら再生するモニター以上の解像度、フレームレート、色域が記録されていても保存に必要な容量が用意できれば全く問題ない
924:login:Penguin
20/01/27 14:05:19 vU+1ytkI.net
>>886
得ろ動画溜め込むのに少ない
925:login:Penguin
20/01/27 18:07:52 udH3RDqL.net
8K24bitの24時間ハメ撮りAVだと無圧縮で計算上約8TBだな
926:login:Penguin
20/02/02 12:09:33 Hg2ze+cG.net
>>836,841,843
この流れ好き
927:login:Penguin
20/02/02 15:16:02 GHB58PtI.net
Linuxのファイルシステム「Btrfs」を5年間使用した記録
URLﾘﾝｸ(gigazine.net)
928:login:Penguin
20/02/02 15:26:44.86 U7jFn1mT.net
RAIDはmd使った方が無難に思える
929:login:Penguin
20/02/02 17:40:25 HE+GXCHP.net
RAID10はmd raidよりbtrfsのほうが安定してる
RAID 1ならmdのほうがいいけど
930:login:Penguin
20/02/02 23:14:15.47 cDfryaOr.net
>>907,908
md の上に何乗せてるん? ext4? xfs?
931:login:Penguin
20/02/02 23:40:34.80 iaNiREzj.net
スーパー32Xに決まっておる
932:login:Penguin
20/02/03 05:01:47.23 9XLDxuL9.net
>>909
RAID1なら何でも乗っける
ESPの多重化もしたいし
それ以外ならファイルシステムのネイティブ機能の方がいいと思う
933:login:Penguin
20/02/03 11:50:13 1h1DB/oS.net
>>910
その発想はなかった。俺は評価する。
934:login:Penguin
20/02/03 23:45:36 OVT3+6Po.net
セガファンは面白いやつ多いのにセガはあれだな
935:login:Penguin
20/02/11 01:11:17 gTMJQSdw.net
2020年2月10日 Linus，次期カーネル「Linux 5.6」の最初のリリース候補版を公開
URLﾘﾝｸ(gihyo.jp)
ここで触れられているZonefsは開発したWDによるとSMR HDDやSSDに適したファイルシステムらしい
What is Zoned Storage and the Zoned Storage Initiative?
URLﾘﾝｸ(blog.westerndigital.com)
936:login:Penguin
20/02/11 10:00:56.86 JmaZPai6.net
ZonefsはPOSIXに準拠していないので既存のファイルシステムを置き換えるものじゃないけどな
937:login:Penguin
20/02/11 22:35:10 F8Fgy0xz.net
f2fsじゃあかんのかね
938:login:Penguin
20/02/15 20:40:39 ko2/1+4j.net
F2FSは最大FSサイズが16TBなのがSMR HDDには今後ネックになる
939:login:Penguin
20/02/15 20:51:22 fQlV7izm.net
FlashFriendly File Systemだからな
HDDとか知らんよ
940:login:Penguin
20/02/15 21:41:41 7ROaKxuF.net
HDDも大容量キャッシュ付き瓦だとあんまりfs側でいじらない方がいいような気がする
941:login:Penguin
20/02/15 23:17:25 Aj0iDWta.net
WinFS でやりたかったDB の機能も付いたファイルシステムってあります？
942:login:Penguin
20/02/16 09:36:26.82 tFc9/bu5.net
>>920
じゃあそれDBでよくね？ってなってどこも開発やめた
943:login:Penguin
20/02/16 11:11:50 Cl0cNLYW.net
最近はDBのためにダイレクトIOのパフォーマンス上げる改善が多い
944:login:Penguin
20/02/19 08:46:06 +vuP13XZ.net
Googleが新しいファイルシステム作ってる
Android用だからLinuxのメインラインに取り込まれるのか分からんけど
ダウンロード中の不完全なファイルでも実行できるらしい
URLﾘﾝｸ(lore.kernel.org)
945:login:Penguin
20/03/20 16:46:34 oDz6Qr3S.net
btrfsはUUIDの変更が鬼門だな
メタデータとUUIDが紐付いているらしくてデータを読めなくなる
946:login:Penguin
20/03/29 17:30:13 ZSfzV/DF.net
btrfs使わなええ
947:login:Penguin
20/03/29 19:29:33.05 A9QWVCnu.net
カーネル5.4で追加されたネイティブexFATは日付の処理にバグ有り
Windows7とfuse-exFATで作成したファイルを5.4のネイティブexFATドライバで見ると、
更新日付がちょうど 1ヶ月＋9時間 遅く表示される
アクセス日付は常に 1979/12/31 9:00:00 と表示される
5.4のネイティブexFATドライバで作成したファイルをWindows7で見ると、
更新日付とアクセス日付がちょうど 9時間 早く表示される
また、5.4のネイティブexFATドライバでマウントしなおすと上記の症状が起こる
つまり、
・読み書き共にタイムロケールが正しく反映されない (日本設定では9時間ずれる)
・読み込みのみ暦月がずれて読み込まれる (書き込み直後はキャッシュされるので症状が見えない)
948:login:Penguin
20/03/29 19:38:05.23 A9QWVCnu.net
あと、5.4のネイティブexFATは日本語処理は問題なかった
日付のずれは地味に困るから一旦fuse-exFATに戻す
949:926
20/03/29 20:21:00.98 A9QWVCnu.net
アクセス日付を更新するだけでも更新日付が一ヶ月後ろにずれることも分かった
サムネイル表示機能を有効にしてたから試しに開いたSDカードの日付情報も派手にやられた
950:login:Penguin
20/04/08 08:54:17.25 ctV6ZAP7.net
Windows10
5000個以上のPDFをAドライブからBドライブに移動させたら、ファイル数はそのまんまなのに総サイズが250MBも減少した
なんで？
951:login:Penguin
20/04/08 09:48:50 h2p5sSpc.net
圧縮ディスクだった
952:login:Penguin
20/04/08 16:48:38 nNfYJP3N.net
Aドライブってフロッピー？
953:login:Penguin
20/04/08 18:26:58 9nhczXSy.net
A側はexfat でアロケーションユニットサイズが 1MB (平均512KB/ファイル余計に消費)で、
B側はNTFSで同サイズが4KBで(同平均2KB/ファイル)だったって感じか？
(意図的にやらない限り 1MB なんて値にはならないはず)
それ以外の可能性としてはA側には隠しファイルがあってサイズは隠しファイル込みだった
954:login:Penguin
20/04/09 01:04:11 NYHCWS9d.net
exFatをWindowsで初期設定でフォーマットするとクラスタサイズが128KiBになる
1ファイルあたり平均64KiB余計に消費するので、64KiB×5000個=約312MiB
>>929 は順当な結果
955:login:Penguin
20/04/09 01:09:19.65 NYHCWS9d.net
1件1ファイルで保存するタイプのメールデータをexFatに保存すると大変なことになる
(1件ごとにほぼ128KiB無駄になる)
あとNTFSは約700バイト未満のファイルはメタデータに直接格納しちゃうから細かい設定ファイルやらメールデータの収納効率が非常に良い
956:login:Penguin
20/04/09 08:50:59.38 tHpWeU4o.net
Ubuntu 20.04β試していて初めて知ったんだけどlinux-5.3あたり（？）からNILFS2へ書き込もうとするとクラッシュする（といってもNIFS2を扱っているカーネルのサブシステムだけ）というトラップ（バグ）が仕掛けられてたのね。
/homeをNILFS2で運用していて18.04でバックポートカーネルを入れるとログインできなくなるんで何でだろうと思っていた。
当分18.04+5.0系カーネルで保持かなあ？
957:login:Penguin
20/04/09 10:29:58.44 wTSYL5PJ.net
NILFS2って保守されてるのか？
いつか消されるんじゃないかと思っているのだけど
958:login:Penguin
20/04/09 12:30:14.75 7wAsdCRN.net
4TB の外付けHDDを exFAT でアロケーションユニットサイズを NTFS と同じ 4kB で使う場合、
大きなデメリットってある？
それとも、アロケーションユニットサイズを変更するくらいなら、素直に NTFS で使ったほうがいい？
Linux でもネイティブ対応しそうな exFAT を考慮したいけど、
今までの外付けHDDが全部 NTFS なので、
ちょっと躊躇してしまう。
959:login:Penguin
20/04/09 12:47:50.43 f9lVta1Z.net
数十～数百GB程度ならexFATでも何でも構わんけど
テラバイトサイズのボリュームはジャーナリングファイルシステムでないと怖すぎないか
960:937
20/04/09 13:13:20 7wAsdCRN.net
>>938
確かに、ジャーナルのない点は少し気になるねぇ。
サルベージするときの復元率の違いも気になる。
FAT32 のときは、復元できても断片になることもあった。
もっとも、NTFS の場合、復元できなければ断片すら拾えないという感じだから、
優劣という感じじゃないしなぁ。
961:login:Penguin
20/04/09 17:40:41 vpGccY6F.net
>>936
ジャップ製モジュールはこれが怖い
962:login:Penguin
20/04/09 18:04:57.35 9fEj1NQk.net
チョン？
963:login:Penguin
20/04/09 22:32:27 4pQr46JD.net
手伝お？
964:login:Penguin
20/04/10 16:47:03 mZNoA7ar.net
>>937
そのFSを読めるOSが壊れたときなんて想定は別の同じOSを用意すればいいでしかないぞ
965:login:Penguin
20/04/11 22:41:34.77 XDts1cPd.net
>>937
Windows95/98と同じ程度の信頼性はあるはず
966:login:Penguin
20/04/24 00:01:20.91 OEQFvFGC.net
CoWはその性質上、空き領域をどんどん上書きするからSSDの速度低下が起きやすいようだ
定期的にトリムした方が良い、例えば毎朝と毎夕
マウントオプションでdiscardオプションを付けても良いがLinuxでは遅くなることが多い
fstrim -v /
967:login:Penguin
20/05/03 18:58:52 njMyCBBl.net
>>935
NILFS2開発者のMLにとりあえずの回避策が流れてた。
起動からマウントまでの間にそのFSのデバイスへの書き込みがあればいいので、
マウントの前に
dd if=/dev/なんとか of=/dev/なんとか count=1
みたいにダミーの書き込みを発生さればいいのだそう。
例えば、fstabから削除かnoautoにしてrc.localとかでdd, mountという流れとか。
968:login:Penguin
20/05/05 05:14:55 AUhfSTN7.net
>>946
ありがとう。
たぶんこれかな↓
URLﾘﾝｸ(marc.info)
自分の場合も/homeがnilfs2なんでどうしたものかな？？？というところですわ。
サブ機のほうはbtrfsに替えてUbuntu20.04に上げたけどメイン機の方はどうするかなあ？
969:login:Penguin
20/05/26 11:43:00 1H93WhIH.net
Btrfsとかzfsって一台のhddだけで運用するのはたいしてメリットないの？
970:login:Penguin
20/05/26 12:46:01.35 +ELcO//y.net
あるだろ
圧縮とかスナックショトとか 盛りだくさんだわ
>>948
971:login:Penguin
20/05/26 17:16:39.31 o4/8jJLs.net
デュアルブートしてたらNTFSのMFTがミラー毎壊れたんですけどなんとかMFTを修復できませんかね？
EaseUS Data Recovery Wizardを使うとディレクトリやファイル名がそのままでデータ救出できるんですけど
という事はMFTも修復できるはずですよね？
972:login:Penguin
20/05/26 22:43:28.04 6YtvPgat.net
Btrfsの将来は
973:login:Penguin
20/05/27 08:05:49.48 uLCM26Hl.net
君の頑張り次第
974:login:Penguin
20/05/27 12:56:13.77 XCSTzVNb.net
まだ始まったばかりだ！
Oracke先生の次回作にご期待ください
975:login:Penguin
20/05/27 20:57:11.66 acGll7c1.net
xfsのCoWを有効化したまま1年以上使ったけど時々フリーズするなやっぱり
あとメモリ使用量がちょっと大きすぎるね。
まだまだext4安定の時代は続きそうだ
976:login:Penguin
20/05/27 21:38:26 0U4TUkPK.net
それならBtrfsの方が安定してるな。できたばかりでこれからなんだろうけど
977:login:Penguin
20/05/27 21:42:16 wyekam7t.net
2017年8月3日 Red Hat，RHEL 7.4リリースで"脱Btrfs"を明らかに
URLﾘﾝｸ(gihyo.jp)
978:login:Penguin
20/05/27 22:26:06 sT3KZO5+.net
ext5開発開始まだー
979:login:Penguin
20/05/28 05:14:42.87 6u6TfIVC.net
うーむbtrfsで組んでる領域どうしよう
compress標準サポートが貴重なんだけどな。
乗り換え先おすすめ教えてください。
980:login:Penguin
20/05/28 09:40:13.16 lg5ytPVY.net
なんでBtrfsなんか選択したんや…
981:login:Penguin
20/05/28 09:46:17.62 bvSCyOR7.net
Synologyが推してるBtrfs
Googleが使ってるBtrfs
982:login:Penguin
20/05/28 09:54:45.61 EreFZKCr.net
btrfsはヤヴァいと何度言えば（ｒｙ
983:login:Penguin
20/05/28 10:35:33.75 kpVDAvmO.net
>>958
zfs
984:login:Penguin
20/05/28 11:26:26.96 ztRPopnD.net
なんだかんだでLinuxで高機能モダンファイルシステム使おうと思うととりあえず何も考えずに使えるのがBtrfsなんだよね。
こまめにバックアップ取りながら人柱のつもりで突っ込んだのに、意外と問題出ないし……
985:login:Penguin
20/05/28 12:31:52 A6PA4iBR.net
Google遣ってるならBtrfsの未来は明るいと思ってしまう不思議
986:login:Penguin
20/05/28 12:36:38 rCbDOGHF.net
>>963
俺も数年使ってるけど何も問題起きてないわ
ぼんやり使ってるだけだから気付いてないだけの可能性もあるけど
987:login:Penguin
20/05/28 14:51:58.35 kpVDAvmO.net
ぐぐたすヲもう忘れたのか?
988:login:Penguin
20/05/28 16:25:14 qJC8ExER.net
IT巨人で信頼できるのはMSだけだわ
Window以外はブッチギリで有能
989:login:Penguin
20/05/28 22:47:31.09 35G/ZT7g.net
Vista以降のWindowsもNTFSも優秀だよ
今時こんな堅牢なOSちょっと無いよ
990:login:Penguin
20/05/29 01:50:04.11 /sA5f8CX.net
URLﾘﾝｸ(wiki.archlinux.jp)
本当に隅から隅まで問題が起きていないのか、問題が起きた時にfsckの類が動くのか、etc
よくbtrfsなんぞ使えるな・・・
991:login:Penguin
20/05/29 05:52:56.10 BCgb8iXY.net
そんなこと言ったらext4もxfsも使えんぞ
992:login:Penguin
20/05/30 22:19:12.00 rxDacgPJ.net
ext4もxfsもBtrfs程の問題は抱えてないだろうて
Btrfsは解決の目途が立ってない既知の問題点が多すぎる
993:login:Penguin
20/05/31 00:36:23.90 O/t7Lowh.net
具体的に何が既知の問題なんだ？
994:login:Penguin
20/05/31 00:46:30.60 4i1+bTSg.net
何故>>969すら見ないのか・・・
995:login:Penguin
20/05/31 00:56:48.74 O/t7Lowh.net
>>973
そこ見たら実験的な機能が多いのは分かるけど
普通に使って問題が起きるようなことは書いていないが
996:login:Penguin
20/05/31 01:04:37 4i1+bTSg.net
マウントオプションを貪らずに一切エラーが起きなきゃな
起きた時が問題だからbtrfs checkで全部を直せないとかマウントオプション云々だとか散々警告されてんだろうに
RedHatが匙を投げたって時点でお察し
997:login:Penguin
20/06/01 15:44:25 RZhBr4iC.net
Googleってbtrfs使ってんの？
998:login:Penguin
20/06/01 18:14:25 7+mv9XDP.net
redhat引き合いに出してbtrfsオワコン唱えるやつ多いけどbtrfs開発者がredhatやめたってだけ
んでまともに触れる社員いないfsはサポート無理ってのとチーム内にXFS開発者ならいっぱいいるからだって元社員がいってたぞ
googleは知らんが大御所で使ってる、貢献してるのはfacebookと富士通とかだな
999:login:Penguin
20/06/01 18:38:32.80 uT4k0Fz5.net
GoogleはChromeOS内のLinux環境で使ってるだけ
1000:login:Penguin
20/06/01 18:40:48.93 2PrO6u28.net
>>978
それってけっこうデカくね？
1001:login:Penguin
20/06/01 19:50:25 OAVwE/lA.net
遭遇してもクリーンインスコすりゃいいって程度のシステムならbtrfsでも問題にならんのだろうけどな
redhatの件が無くてもbtrfsは昔からモグラ叩きの繰り返しだし、
未だにRAIDやファイルチェック周辺すら完全にできてないし、どこに地雷があるかわからん
一部のfsのエラーを修復できませんって、そのエラーに遭遇した時にどうすんだよと
1002:login:Penguin
20/06/01 21:36:44.83 9JaREmBh.net
クライアント(スナップショット/RAIDなし)で使えててもファイルサーバで
安心して使えるかというとそうじゃないからなあ
1003:login:Penguin
20/06/01 21:56:25.70 2PrO6u28.net
スナップショットもRAIDも使ったし、オンラインでストレージ構成変えまくったけど問題出なくて（しかも構成変更が柔軟過ぎて）拍子抜けしたんだよなぁ。
ファイルサーバ用途でこそ輝くよこれ（バックアップはこまめにね）
1004:login:Penguin
20/06/02 11:47:13 6oGgMjKL.net
ファイルサーバーっていう言葉で考えているものが全然違う二人で会話してる感じがする
1005:login:Penguin
20/06/02 12:27:10 sg8jbCA1.net
Terastation クラスの NAS(Btrfs 利用だと Synology の製品)/エントリークラスか
会社のファイルサーバ(Isilon や NetApp やその対抗製品クラス)/
エンタープライズクラスかってことかな
クラウド化やセキュリティ強化が進むにつれてエントリークラスの需要は
落ちる/落ちてるんじゃないかな
1006:login:Penguin
20/06/04 01:47:45 xNtEdgfL.net
ノートPCをCoW有効にしたXfsにしてるけど
メモリ使いすぎて本気で後悔してる。
省メモリなFSだとext4が良いのかな？
どこかにFSごとのメモリ使用量の比較データとかあたりしない？
1007:login:Penguin
20/06/04 07:54:18.56 gBysGF/t.net
そんなにメモリ食うの？
1008:login:Penguin
20/06/04 09:23:07.24 Bs6FKlOi.net
信じられないくらい食う
プロセスの合計メモリ使用量は大したことないのに
簡単にスワップ突入するよ。
1009:login:Penguin
20/06/04 09:40:20.48 DMZuMarq.net
CoWとジャーナリングなら比べるのも愚かというレベル
1010:login:Penguin
20/06/04 09:51:37.00 Bs6FKlOi.net
というかカーネル4.18からDefaultでreflink有効になったのかよ・・・
URLﾘﾝｸ(blogs.oracle.com)
もはやxfsは別物じゃん
1011:login:Penguin
20/06/04 11:31:13.32 DQZXMKEK.net
>>985
使ってないけどメモリ制限できるんでは？
1012:login:Penguin
20/06/04 12:01:52.27 gBysGF/t.net
dedup使ってるとかでもなしにそんなメモリ食うのか。
Btrfsがメモリ食わないからCoW自体は対してメモリ食わないものだと思ってた
1013:login:Penguin
20/06/04 15:07:25.35 x4v3XzWR.net
CoWを無効にしたXFS使って比較しろよ
1014:login:Penguin
20/06/04 17:36:35.28 7r9XEAZX.net
>>946
これはGood News?
>> Wondering if it can be reproduced on mainline with c3aab9a0bd91
>> ("mm/filemap.c: dont initiate writeback if mapping has no dirty pages")
>> reverted?
>
> For mainline kernels with that commit reverted, this oops actually
> doesn't occur.
URLﾘﾝｸ(marc.info)
1015:login:Penguin
20/06/05 14:07:47.91 jA3wZpDc.net
>>993 で引用された部分は
「ホントにc3aab9a0bd91なしだと起きないん？」「そだよ」
と言ってるだけだけど、
落ちるまでの流れはわかったっぽいしまだ不安定ながらパッチもできた、
というのが現状かな。
1016:login:Penguin
20/06/08 15:13:54.40 PPU2wP+g.net
>>994
で、もう正式に入れてちょうだいってパッチも出たんだけど、
実質1行追加するだけだった。
こういうパッチ好き。
実際どうかは知らないけど、いかにも問題を追求し切ったって感じがして。
1017:login:Penguin
20/06/13 14:52:24.01 Qx8FdC0t.net
次スレ
ｽﾚﾘﾝｸ(linux板)
1018:996
20/06/13 14:53:58.96 Qx8FdC0t.net
なぜか、NGに引っかかったので、関連スレの途中までしか書けていません。
あと、リンク切れの場合は、ご容赦ください。
1019:login:Penguin
20/06/13 14:54:55.61 Qx8FdC0t.net
次スレ
ファイルシステム総合スレ その18
ｽﾚﾘﾝｸ(linux板)
1020:login:Penguin
20/06/13 14:55:57.84 Qx8FdC0t.net
間違えた。
ファイルシステム総合スレ 「その19」
でした。
ｽﾚﾘﾝｸ(linux板)
1021:login:Penguin
20/06/13 14:56:51.52 Qx8FdC0t.net
ファイルシステム総合スレ その19
ｽﾚﾘﾝｸ(linux板)
1022:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 897日 15時間 6分 0秒
1023:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています