[過去ログ] ファイルシステム総合スレ その18 (1002レス)
上下前次1-新
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
654: 2019/08/22(木)06:15 ID:dj60c2S0(2/2) AAS
たしかに。
655(1): 2019/08/22(木)11:06 ID:NSVYAGiU(1) AAS
ファイルシステムはサイズがPBを超えてからが勝負
656: 2019/08/22(木)12:20 ID:m9kjglry(1/2) AAS
Unicode対応はFAT12でもVFATなら対応可能って奴じゃないの?
MS-DOSで見ると謎の文字列になるやつ
FreeDOSでもそうじゃなかったっけ?
UEFIはどうだったか覚えてない
>>655
個人で勝負に挑むには、月間の消費電力どれくらいになるんだろう
657: 2019/08/22(木)12:21 ID:jWTG6YZX(1) AAS
FAT64を作れば最強じゃね?
658: 2019/08/22(木)12:36 ID:m9kjglry(2/2) AAS
新たに作らなくてもexFATでいいんじゃね?
659: 2019/08/22(木)16:22 ID:pq9swZ6w(1) AAS
誰かVirtual Data Optimizerを試した
人はいませんか?RHEL 7.5から使える
重複排除の機能拡張っぽいのだが。
外部リンク:github.com
660: 2019/08/22(木)16:40 ID:c/3upDZj(1) AAS
>>550
実装できたみたいね
661: 2019/08/25(日)20:40 ID:hTk0r0Sf(1) AAS
exFATはほぼFATじゃないでしょ。少なくともFAT32やらとはかなり互換性を失なってる…筈。
662: 2019/08/26(月)14:38 ID:ebuP7us/(1) AAS
ディスクの扱える最大容量が違うのに
互換性なんて持たせられるはずがないべ
663: 2019/08/26(月)18:10 ID:Q2M/7GD/(1) AAS
bcachefsの登場で
中身のファイル名が長すぎて解答できないRARファイルが
いよいよ解凍可能になるぜ
664(1): 2019/08/27(火)23:26 ID:cl90n3Lm(1) AAS
40年前に100EBのファイルシステムを想定したFS作ってればよかったのに
665: 2019/08/28(水)00:51 ID:roj4LxzO(1) AAS
そんなの作ってもメモリ不足で使えねえよ
666: 2019/08/28(水)02:44 ID:K9W23MUl(1) AAS
大容量でもメモリ不足にならないよう作れるだろうに。。
667(1): 2019/08/28(水)03:13 ID:XY99YJWD(1/5) AAS
仮にメインメモリが不足しなくっても上位bitが無駄になりまくって記憶媒体の無駄遣いになってたろう
当時のKB単価知らんのけ?
668: 2019/08/28(水)03:24 ID:jakMXSf+(1) AAS
俺がコンピュータを使い始めた頃は1MBうん十万なんて時代だったしな
669: 2019/08/28(水)07:49 ID:j5W+ovEv(1) AAS
ビット単位で惜しんで実装する時代だったな
そんなもん設計しても実装して運用出来るメモリ容量がない
670: 2019/08/28(水)07:59 ID:db/ocE9c(1) AAS
>>664
64KBあれば個人には使い切れない(笑)
と云われていた時代に何を云うとるか(笑)
671: 2019/08/28(水)08:09 ID:jUTn4eZr(1/2) AAS
ビルゲイツ「640KBのメモリがあれば十分」はデマだった [無断転載禁止]c2ch.net
2chスレ:prog
ビルゲイツが言ったとされる「640KBのメモリがあれば十分なはずだ」は実はデマでした
本人自ら行っていないと明言しており、第三者の調査でもそのような発言は見つかっていません
外部リンク[htm]:pc.watch.impress.co.jp
> 「640KBのメモリがあれば十分なはずだ」なんてことを言った覚えはないんだけど。
> 2005年のWinHECは、ビル・ゲイツ会長のこんなジョークともボヤキとも受け取れる言葉で始まった。
その発言の動画
動画リンク[YouTube]
> Bll Gates at WinHEC. Claimed to have never said that computer would never need more than 640K memory
省14
672: 2019/08/28(水)08:09 ID:jUTn4eZr(2/2) AAS
いつの間にか「ビルゲイツ 640KB」で検索したら↑のスレが
一番目に来るようになってるなw
673(1): 2019/08/28(水)08:20 ID:U92vyvJf(1/3) AAS
>>667
お前が設計したら無駄になりまくるからといって
それがもっとも効率が良い設計だと思わないで
674(1): 2019/08/28(水)08:38 ID:XY99YJWD(2/5) AAS
>>673
100EBを表現しなければならない可能性のあるとこには必ずそれだけのbitが必要になる筈なんだが
可変長符号化だってコスト0(bit)って訳じゃないんだぞ
675: 2019/08/28(水)08:47 ID:/ip8C1e4(1) AAS
考え方次第で最初に全サイズを読み込んでそれに基づいたbit割り振るようにすればいいだけなのでは?
676: 2019/08/28(水)09:27 ID:XY99YJWD(3/5) AAS
そのサイズは何bitでわかる?w
677(1): 2019/08/28(水)10:29 ID:U92vyvJf(2/3) AAS
>>674
100EBを表現しなければならない状況でそれに必要なbitを使うのは無駄ではない
問題は100EBを表現しなくてもいい状況で無駄に使わないことだろ
678(1): 2019/08/28(水)10:33 ID:XY99YJWD(4/5) AAS
>>677
だから1byteなのか2byteなのか3byteなのかの可変長符号にもコスト掛かるっつってんだよw
679: 2019/08/28(水)11:26 ID:U92vyvJf(3/3) AAS
>>678
コストが掛かるのは当然だ
コストゼロでなければ「無駄になりまくって」るというならお前の頭がおかしい
680: 2019/08/28(水)12:33 ID:XjV2vzUW(1) AAS
そもそも容量増加スピードなんてのは予測できるわけでそれに合わせてFSもロードマップ作って拡張すりゃよかったんだよ
681: 2019/08/28(水)21:30 ID:XY99YJWD(5/5) AAS
当時のKB単価もビット判定やら何やらに掛かるステートも知らずに、後出しで難癖付けるだけなんて簡単でいいよな
てかそう思ったんならおまえが普及させりゃ良かっただろっていう
682(1): 2019/08/28(水)21:35 ID:+xLGKmxQ(1) AAS
今だと瓦HDDに最適化したファイルシステム開発したら歓迎されそう
(もうどこかやってるかな?)
683: 2019/08/29(木)01:12 ID:VQiAWJJ4(1/2) AAS
瓦HDDの中でホスト側で制御するものは、その手のファイルシステムを前提にしている
684: 2019/08/29(木)01:16 ID:VQiAWJJ4(2/2) AAS
瓦は読み込みと書き込みの最小単位が異なる点でSSDと同じなので
SSD向けのファイルシステムが効果的な可能性が高い
例えばCoWやバケット単位の管理を採用したやつ
685(2): 2019/08/29(木)06:53 ID:yqJY2zQ1(1) AAS
>>637
外部リンク[php]:www.phoronix.com
> Microsoft Publishes exFAT Specification, Encourages Linux Support
キタ━━━━(゚∀゚)━━━━!!
686: 2019/08/29(木)08:24 ID:ayv/fTUM(1/2) AAS
>>685
やっぱりMicrosoftは正義やな
687(1): 2019/08/29(木)09:17 ID:57E44Kd+(1) AAS
最近は反MSの連中よりMSのほうがOSSに貢献してる
688(1): 2019/08/29(木)09:31 ID:oTY9cNJu(1) AAS
ntfsも公開してくれよん
689(1): 2019/08/29(木)10:37 ID:IgCGENYH(1) AAS
>>685
キタ━━━━(゚∀゚)━━━━!!
690(1): 2019/08/29(木)11:53 ID:ayv/fTUM(2/2) AAS
>>688
NTFSは公開してもファイルシステムの高度なセキュリティ能力を
Linuxにマッピングできないのであまり意味がないな
691(2): 2019/08/29(木)12:26 ID:5xSjyKa3(1) AAS
>>682
瓦最適化はWDの中の人がbtrfsにパッチ投稿中。
692: 2019/08/29(木)18:23 ID:17OYqypV(1) AAS
Microsoft、Linuxカーネルで公式に「exFAT」サポート
外部リンク[html]:www.itmedia.co.jp
693: 2019/08/29(木)18:31 ID:3gIOV6hV(1) AAS
>>691
はえー。俺の鯖ちょうど瓦でbtrfsだわ、ありがてえ
694: 2019/08/29(木)20:54 ID:7ODgbVNJ(1) AAS
>>687
反MSって具体的になに?Oracleとか?
695(1): 2019/08/29(木)21:12 ID:V76BsNE3(1) AAS
Windows Storage Server 2016の重複排除機能、優秀すぎてワロタ
696: 2019/08/29(木)21:56 ID:71eCL6Dr(1) AAS
>>689
どちらかというと、ユーティリティ側の出来がよくなってほしいな(´・ω・`)
今、fsck.exfatがチェック出来るだけ状態だからね。
マウントするだけならfuse経由でできるし。
697: 2019/08/29(木)22:30 ID:/Ysvkkai(1) AAS
>>695
今のところ重複排除がまともに運用できるのWindows Serverだけだな
ZFSも一応使えるけど使う人居ないだろって感じの実装
698: 2019/08/30(金)01:10 ID:49Usa2R4(1/4) AAS
>>690
同じ理由でextXもWindows上では使い勝手が非常に悪い
NTFSもextXもシステムに特化しすぎて細かい仕様がなじまない
低機能なFATがいまもデータ交換用に普及してる理由でもある
699: 2019/08/30(金)01:11 ID:49Usa2R4(2/4) AAS
exFATの構造
外部リンク[txt]:homepage3.nifty.com
700(1): 2019/08/30(金)01:18 ID:49Usa2R4(3/4) AAS
exFATは他の近代ファイルシステムに合わせてメタデータをファイル化したのはいいけど
FATが固定テーブルのままだから空き領域ビットマップも固定テーブルで良かったと思う
あとFATエントリが32bitのままだから16TB超えると影響出始める
リムーバブルで16TBは当分先とは言え将来はわからないぞ
701: 2019/08/30(金)01:41 ID:49Usa2R4(4/4) AAS
MSがさっそく公式に公開してたじゃないか
外部リンク:docs.microsoft.com
702: 2019/08/30(金)04:24 ID:itEjT5Wb(1/2) AAS
>>700
> あとFATエントリが32bitのままだから16TB超えると影響出始める
exFATの理論上の最大ボリュームサイズは128PB(ペタバイト)だよ
128 * 1024TB = 131,072 TB。実装上の問題で 512TBが推奨とされてるけど
外部リンク:en.wikipedia.org
703: 2019/08/30(金)04:38 ID:itEjT5Wb(2/2) AAS
なるほど、FAT32は名前に反してクラスタ数として28bitしか使ってなかったのか。(exFATは32bit)
1クラスタのサイズがFAT32は32KBまでだから、FAT32の理論上のボリュームサイズは8TB
exFATでは32bit全部を使うから、これだけでも128TBまで使えることになるが、
さらに1クラスタの最大サイズが32KBから32MBに増えたから、理論上のボリュームサイズは128PBになるんだな
FAT32もexFATも実際の実装はそこまで対応してないから減るわけだけど
将来的に対応の必要性があれば互換性を保ったまま増やせるわけか
704(1): 2019/08/30(金)11:49 ID:xVO3b390(1) AAS
>>691
btrfsなんて不安定で微妙なFSじゃなくってext4とかXFSで瓦対応してクレヨン……
と思ったが瓦はCoW向きなのか
だったら仕方ないかorz
705: 2019/08/30(金)18:29 ID:BfSogZjl(1/2) AAS
マジかよ今後はexfat一択じゃん
706(1): 2019/08/30(金)19:36 ID:wK/ekzyO(1) AAS
でもexfatってジャーナリングファイルシステムじゃ無いんでしょ
707: 2019/08/30(金)20:17 ID:BfSogZjl(2/2) AAS
マジかよじゃあexfat要らね
708: 2019/08/30(金)21:52 ID:xOfxtSvx(1) AAS
やっぱりntfsが最強だな
709: 2019/08/30(金)22:33 ID:lt7x2d9b(1) AAS
>>704
xfsはSMR対応やる気あるだろ
710: 2019/08/31(土)01:01 ID:PjcUVRL7(1/2) AAS
xfsのCoWがどんな感じかだな
btrfsはCoWだけじゃなくパケットライトのような構造でSSDへの負担の軽減と効率化を図っている
副作用でデータベースのようなランダム書き換えを繰り返す用途と非常に相性悪いけどな
711: 2019/08/31(土)07:09 ID:R786WVAl(1) AAS
>>706
> でもexfatってジャーナリングファイルシステムじゃ無いんでしょ
ジャーナル対応は可能だよ。
712: 2019/08/31(土)09:11 ID:PjcUVRL7(2/2) AAS
可能なのと実装しているのは大きく違う
ext2にジャーナルファイルを追加してext3としたように後付ならどうにでもなるが
それでも名前を変えるレベルの変更になる
互換性が重要なリムーバブル向けで大きな変更はできないだろうな
exFATは冒険を避けたのか内部的にはけっこう中途半端な拡張になっている
713: 2019/08/31(土)11:53 ID:M9ADFjBr(1) AAS
ディレクトリエントリ構造がvfat引き継いでんのがクソ
714: 2019/08/31(土)12:43 ID:KGfTBrB+(1) AAS
kwsk
715: 2019/08/31(土)14:12 ID:JnSDyXRZ(1) AAS
kwskっていうのはクソの理由だぞ。
vfat引き継いでるということの説明をされても
クソの理由にはならないからな
ってかvfat引き継いでないがなw
716: 2019/09/03(火)17:02 ID:yL/ahKNe(1) AAS
Linuxに関して言えば,
組込みLinuxが入ってる携帯端末とかはexFATを採用しそう。
そうじゃないのはXFSやext4でいい(「でいい」というか,「が十分使える計算機資源がある」
717(3): 2019/09/03(火)17:44 ID:xfgJCc5v(1) AAS
exFATを使うというのが単に外部ストレージのファイルシステムとして受け付ける(マウントして読み書きに対応できる)という話なら対応が進むだろうが、
システムやユーザーディレクトリがexFAT上に置かれるようになる、システムパーティションとしてexFATが採用されるという話なら、それは無いんじゃないの?
システムパーティションとしてFATやexFATを利用可能な実装、あるならそれがデフォルトの実装というものが実在するなら、むしろ見てみたい(提示して欲しい)。
パーミッションなにそれという無法の罷り通る組み込み実装というものが実在するなら恐ろしい話だ。
NTFSならUNIXの(POSIXの)パーミッション機能を全て内包した上でより高度かつ緻密な権限設定なども可能だが、それらの機能をUNIXからは満足に扱えず持ち腐れるしかないし、
NTFSをシステムパーティションとして設定可能なディストリというものも記憶に無い(Windowsとの共存を念頭に既存のNTFSパーティション内に構築されるものならあったが)
718: 2019/09/03(火)19:05 ID:B9+IOgvJ(1) AAS
Androidではf2fsとext4が使われているな
これは端末によって分かれる
それとユーザー領域にsdcardFSとか言うのが使われている
719: 2019/09/03(火)19:52 ID:8FoKpEbS(1) AAS
>>717
今北産業
720: 2019/09/03(火)20:37 ID:2aAU5+p7(1/2) AAS
>>717
今でも使えるか知らないけどUMSDOSというFAT用の拡張があるよ
仕組みはVFATのような感じで長いファイル名とパーミッション等を使える
いにしえの文書
外部リンク[html]:archive.linux.or.jp
それとNTFSのACLと同等の機能はXFS等でも使えるようになっているよ
721(1): 2019/09/03(火)20:56 ID:2aAU5+p7(2/2) AAS
>>717
ACL関係もいにしえの文書だけど
外部リンク[html]:www.itmedia.co.jp
POSIX ACLはSamba以外では積極的に使われない機能だから
あまり解説されていないだけ
722: 2019/09/04(水)01:58 ID:AfE9OQrQ(1) AAS
>>721
NTFSと同等なのはPOSIX ACLじゃなくてNFSv4 ACLとか、HFSやAPFSに実装されている方
723(2): 2019/09/09(月)22:59 ID:SszYAJmS(1) AAS
互換性は別にして、機能としてPOSIX ACLになくて、NTFSやNFSv4 ACLにある物って何があるの?
デフォルト値とかが違ってWindowsと全く同じ挙動にはできないけど、機能的には同等だと思ってた。
724(2): 2019/09/10(火)02:47 ID:7v2JkFhP(1) AAS
>>723
POSIX ACLはパーミッションの素直な拡張で、
・ユーザーやグループ毎にRWXの3種類の許可のオンオフ
・ディレクトリにデフォルト値を設定して子孫に継承させる
だけ。
NTFSの方は、そもそも権限が13種類ぐらいあって複雑怪奇。例えば、
・属性(タイムスタンプとか)の読み込みだけ許可
・ファイルへの追記だけ許可(上書きは不可)
・ファイルは作れるけどサブディレクトリは作れないディレクトリの実現
・ファイルの削除権限をファイル自体に設定
省9
725: 723 2019/09/10(火)03:14 ID:ux9dqJdd(1) AAS
>>724
おお。確かに全然違う。NTFSそんなに機能あったのか。
勉強になった。ありがとう。
726: 2019/09/10(火)04:08 ID:QHsS5imR(1) AAS
機能的にはミニコンやメインフレームで大規模なDB載せるような用途にも対応できるような作りだしねえ…
これでもう20年も実績あるんだから、いっぱしのファイルシステムですな >NTFS
727: 2019/09/10(火)04:31 ID:c/QawrHU(1/3) AAS
そのNTFSの機能はだいたいZFSで網羅してるな
728(1): 2019/09/10(火)05:23 ID:h9c2d3nY(1) AAS
ZFSで網羅してるとして、何のコマンドでやるの?
ZFS専用コマンド?
729(1): 2019/09/10(火)06:24 ID:hXcE461p(1) AAS
ZFSってIRIX発祥だったように記憶しているのだけど
IRIXはつまり一般的なPOSIXの枠を超えたACLを独自に実装していたということですかね?
730(2): 2019/09/10(火)06:35 ID:c/QawrHU(2/3) AAS
>>728
意外なchmodで全部行ける。まるで呪文だがw
setfacl -m owner@:full_set:allow,group@::allow,everyone@::allow acl_test.txt
外部リンク[html]:docs.oracle.com
>>729
Solarisでそ?
731(1): 2019/09/10(火)06:41 ID:c/QawrHU(3/3) AAS
>>730
自己レス
ごめん
chmod A3=user:venkman:read_acl:allow filename はSolaris
freebsd はsetfaclでやる実装だった「
732(1): 2019/09/10(火)13:55 ID:6sIzNa2X(1) AAS
> 729
XFSはIRIX
ZFSはSolarisです。
733: 2019/09/10(火)15:10 ID:TIJq+nNn(1) AAS
ext4でいいじゃん
734: 2019/09/10(火)16:55 ID:+5M9tkhk(1/2) AAS
>>724
詳しい解説サンクス!
多すぎて頭がフットーしそうだよお
735: 2019/09/10(火)16:56 ID:+5M9tkhk(2/2) AAS
>>730,731
こっちも詳しい解説サンクス!
736: 2019/09/10(火)19:00 ID:nfLMQN5s(1) AAS
>>732
ああそうだ、IRIXはXFSだったわごめん
おれ個人では普通に信頼してるFSだけど、Linux界隈では個人だと使ってる人あまり見ないよね…
737: 2019/09/11(水)01:29 ID:U4ts0n/J(1/2) AAS
LinkStationのデフォルトがXFSだったはずたから知らないうちにXFS使ってる人は案外いそう
738: 2019/09/11(水)02:15 ID:XGTr0XqS(1) AAS
CentOS7のデフォルトがXFSだから、個人でも使っている人は沢山いるはず
739: 2019/09/11(水)09:22 ID:Im0aUzbI(1/2) AAS
NTFSってマジで「多」機能なんだな
740: 2019/09/11(水)20:34 ID:U4ts0n/J(2/2) AAS
多機能すぎてその詳細を理解してる人も使いこなせる人も少ない…MSにさえ
おまけにフルに機能使いこなそうと思ったら非公開API使わなきゃいけないとかいう残念さ
741: 2019/09/11(水)22:52 ID:Im0aUzbI(2/2) AAS
Facebookリンク:dnobori
これを思い出した
742: 2019/09/12(木)08:02 ID:A7RqdNx4(1) AAS
素直にXFS使っとけ
743(1): 2019/09/12(木)14:07 ID:kpioEvUr(1) AAS
XFSは多機能すぎて誰も使いこなせない
744: 2019/09/13(金)10:02 ID:/kG8R/3p(1) AAS
LinuxのXFSにもGRIOあるのかなぁ
745: 2019/09/15(日)08:26 ID:A0tbtNjH(1) AAS
EROFSがLinux5.4でメインライン入りするらしい
リードオンリーファイルシステムだから使いどころは限られるが
すでにスマホで動いているので実績はある
746: 2019/09/15(日)09:51 ID:uMzOqD6G(1) AAS
え、エロFS……
747: 2019/09/15(日)13:31 ID:ua5r3kDz(1) AAS
エッチFS!
748: 2019/09/15(日)17:37 ID:3/04JcE1(1) AAS
>>743
何で圧縮は無いの?
749: 2019/09/16(月)01:54 ID:rJPiMVYE(1) AAS
huawaiのスマホのsystemパーティションでEROFS使われてるのか
androidのsystemは元々リードオンリーでマウントされてたから有用だろうな
750(3): 2019/09/16(月)21:49 ID:8Mnz6MjR(1) AAS
くだらない質問で恐縮なのだが、
既存の、RW可能なファイルシステムで作成したボリュームをROでマウントするのはわかる。
しかしリードオンリーのファイルシステムとなると、
マウントするボリュームは、一体どのような手段で作成されるのだろうか?
卵が先か、鶏が先か…
751: 2019/09/16(月)22:16 ID:Fjxy1taP(1) AAS
>>750
.iso (ISO9660 ファイルシステム、DVD-ROM 等に使われるリードオンリーのファイルシステム)
ファイル作ったことないですかそうですか
752: 2019/09/16(月)22:20 ID:M+XuPW8F(1) AAS
>>750
別のファイルシステムから変換するのでは?
少なくともISO9660はそういう感じだよね。
原理的に、仕様がわかっていて、どういう風にファイルを用意したいか決まっていれば、
ビット列は生成可能なのだから、鶏が先か、卵が先かという問題ではないような気がするけど。
753(1): 2019/09/16(月)22:23 ID:v2xaK5dV(1) AAS
erofs-utilsに入っているmkfs.erofsで作るらしい
外部リンク:git.kernel.org
上下前次1-新書関写板覧索設栞歴
あと 249 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル
ぬこの手 ぬこTOP 0.040s