ファイルシステム総合スレ その18
■ このスレッドは過去ログ倉庫に格納されています
ブロックチェーン処理に特化した中国製ファイルシステム「TCFS」 劉尭 2018年7月10日 19:25 https://pc.watch.impress.co.jp/docs/news/1132183.html 中国・深セン市網心科技有限公司は6日(現地時間)、ブロックチェーンの処理に特化したという ファイルシステム「Thunder Chain File System(TCFS)」を発表した。 これは同社が展開しているクラウドサービス「迅雷」の数百万のP2Pネットワークノードの基礎の 上で、ブロックチェーン処理と分散に特化したファイルシステム。 merkle DAGファイル管理技術に基づいており、ファイルのすべての変更履歴を保存し、過去を 遡って検索できる。ハッシュインデックスも暗号化し、ファイルに変更があったさいに新たなハッシュを 発行することで、ファイルの改竄を防ぐ。 データは前方誤り訂正(FEC)を使って保存され、冗長データをほかのノードに保存することで、 ファイルの破損を自動的に修復することで、データの信頼性を99.9999999999999%までに高めた。 さらに公開鍵と秘密鍵を利用したユーザーとファイルの関係性の維持、トークンを用いたユーザーの アクセス権限の管理といった機構も備える。 応用としては、音楽ストリーミングサービスにおけるライセンス管理、透明性の高いオンライン トレード、機密性の高いデータの保存などを挙げている。 NTFSで32MBクラスタ使えないのかな 実は勝手に諸元を書き換えて32MBクラスタ使えるとかにならないのかな クラスタを32MBに出来れば、SMRの使用感が少しは改善されそうだと思うのに バックアップ用のHDDって最悪Windowsでも読めるようにNTFSにしといたほうが無難? 復旧しやすいようにソースと極力同じになるように設定する事もある 条件次第じゃないか USBブート出来るOSで読めたほうが良いって考え方もあるしね 一概には言えない というか、お好みで、としか 今どきVirtualBoxとかでWindows上でLinuxを動かせるんだから、 Windowsが対応してないファイルシステムでもファイル取り出しは問題ないと思うんだけど まずは東京大学理学部数学科に入らなくては。 院はできればハーバードかプリンストンかオックスフォードかケンブリッジに入りたい。 そのためには東大の頃にダントツの成績でないと駄目だな。 ZFSで突然、あるディレクトリが書き込み不能になる 別のディレクトリを作成してファイルをmv それらファイルが消滅してどこにも見当たらない 元のディレクトリをrmdirしようとすると、Directory not empty ファイルは残ってそうなのに見えない 復活の呪文ありますか? データ領域もジャーナリング機能のついたファイルシステムにしたほうが良いんですか? >>199 本当にお前はダメな奴だな ここの住人は皆んなハーバードかケンブリッジを首席で卒業した奴らだぞ 分かったならマルチしてないで勉強しなさい >>201 起動時に毎回fsckと戯れたいなら好きにすれば良いと思うよ 自分らが触れる機会があるのはMIT or ケンブリッジ のコードだもんな パーティションごとにファイルシステムが違ったらどうなるんだろ。 /homeを初期化したくなかったので/homeはext4のまま、 その他はbtrfsにしてみた。そうしたら一見して問題は起こらなかった。 でもまだ長期間使用していないから分からない。 >>210 別になんともならんよ /boot だけext2 で残りは xfs とかよくあったし、さらには /home は nfs にして Solaris のマシンと共用とか普通に使ってた exfatってtrimに対応してますか? USBブート用のLinuxのファイルシステムで悩んでいるのですが winに差し込むとうっかりフォーマットするリスクを抑えるためにexfatにしようか考え顔なのですが 流石に今どきTRIM未対応のファイルシステムは論外なので。 >>213 何度か試したが、exfat では(機器によるかもしれんが)そもそも EFI ブートしない。 https://en.wikipedia.org/wiki/EFI_system_partition > UEFI firmware supports booting from removable storage devices such as > USB flash drives. For that purpose, a removable device needs to be > formatted with a FAT12, FAT16 or FAT32 file system, FAT12かFAT16かFAT32でないとブートできないみたいよ 最近の Windows10 では修正されたけど、以前の Windows10 や 8.1 以前はパーティション 切ってある USB メモリは最初のパーティションしか認識しないんだよね。 USB HDD だと2つ目以降のパーティションが見えるのが不思議だった。 昔のWindowsの仕様の方が良かったな 先頭だけをvfatにしておけば誤フォーマットすることもなかったし IOスケジューラの話ってどこのスレでやればいいのかね LinuxのデフォルトをBFQにする話が出てるけど >>222 ずっとArchでzenカーネル使ってるけど不具合もないしいいんじゃないの。 >>2 いつものメリケン基準で、ファイル名なんか256バイトもあれば十分よyeah とか言っちゃって決めたんだろ。マルチバイト文字とか考えちゃいねぇ その点Windowsは最初から国際化対応。256文字は必要だから 1024バイトだなって1993年、Windows NT 3.1の頃から対応されてる リンク先では63文字と書いてあるけど、IVSとかIVDとか考慮すると最低32文字だからな 漢字1文字が最大8バイト、Unicodeの「IVS」とは? https://tech.nikkeibp.co.jp/it/article/COLUMN/20100126/343783/?ST=spleaf& ;P=2 Windows10はパス長最大260文字の制限が撤廃されたな デフォルトだと互換性維持のために制限された状態だから設定変える必要があるけど ずっと前から260文字なんて超えられてる MAX_PATHなんてC言語などでWin32を直接使っていた場合で、 たいていの言語では関係ないからな (この世界はもう俺が救って富と権力を手に入れたし、女騎士や女魔王と城で楽しく暮らしてるから、俺以外の勇者は)もう異世界に来ないでください。.zip が保存できません! リナクスのは母型となる仮想ファイルシステムで制限あるんだっけ extの改良だけでは済まないかと 暇つぶしに fuse で超長い名前通してみたけど、通るね raiserfsが4,032 bytes/255 characters、Reiser4が3976 bytesだから どこかに制限あるとしても簡単に変更できるようなってると思う >>233 >>232 は211バイトだからね 73文字(うち4文字は1バイト)で63文字を超えてるけど 多くの日本語文字は1文字で3バイトなので、69*3 + 4 = 211 バイト 63文字っていうのはUTF8で全部4バイト文字を使った場合 JIS X 0213の第3・4水準漢字の一部や、絵文字なんかが4バイト だから一般的には85文字が限界 AKBの 「鈴懸の木の道で『君の微笑みを夢に見る』と言ってしまったら僕たちの関係はどう変わってしまうのか、僕なりに何日か考えた上でのやや気恥ずかしい結論のようなもの」 が76文字(228バイト)だから、もう少し余裕があるな。 アダルトビデオのタイトルは252文字とかすでにext4の限界を突破している。 (252文字と書いてあるサイトを見つけたが実際には249文字だった。 拡張子込みでNTFSの255文字ギリギリ追加い切ってるのかもしれんなw) WinとLinuxの文字数制限は分かったけど Macの文字数制限はどうなってるの? あれもLinuxと同じ255バイト制限? >>238 こっちにまとまってたよ https://en.wikipedia.org/wiki/Comparison_of_file_systems 主要なのを抜き出すと HFS Plus ・・・ 255 UTF-16 characters APFS ・・・ 255 UTF-8 characters ext4 ・・・ 255 bytes ReiserFS ・・・ 4,032 bytes/255 characters Reiser4 ・・・ 3,976 bytes ZFS ・・・ 255 bytes Btrfs ・・・ 255 bytes exFAT ・・・ 255 UTF-16 characters FAT32/FAT32X ・・・ 8.3 (255 UCS-2 characters with LFN) NTFS ・・・ 255 characters( UTF-16 code unit ) ReFS ・・・ 255 UTF-16 characters 思ったんだけど、UTF-16はサロゲートペアとか使われたら最小127文字かもしれない LinuxはReiser4を使えばext4の限界突破できるのか ReiserFSの 4,032 bytesなのに255 charactersってのがよくわからんが(1文字最長16バイトを想定?) どうでもいいけど、こういうデータは各言語ごとに作成するのって無意味だよなぁ ほんま文字数制限ゴミやな。 中国人が新しいFSを作ってくれるのをまつしかないか。 ファイル名に長文使えるとどんなことに便利なの? 煽りではなく純粋に使いみちが思い浮かばない… >>240 255文字のFSはあるしそっち使っては? 伝統的なext、xfsは多分変わらんと思う 新しいFSが出てくるならNVDIMMとか 普及してDAXが流行るころかな fuse 製なら1ヶ月あれば俺でも作れるけど 馬の骨製はいらんやろうな >>241 JANコードをファイル名にするよりも 「JANコード + タイトル」の方がわかりやすいやろ? >>243 うーん俺は>>241 じゃないけど 例えばタイトルにスラッシュが含まれてたらもう絶対ファイルの名前にできないじゃん。 だったらファイル名は純粋な整理番号にして,それにメタデータという形でタイトルや作者の情報を添付する。 そしてファイルマネージャで閲覧したときは,その設定したメタデータが見えるようにできたらよくね? >>243 なるほど ただlsで表示するときに長文名すぎると邪魔じゃないの? 保存時にタイトルが長いと エラー出るからな 例えばWinのファイルをLinuxに移してバックアップしようとしたら ファイル名が長すぎて一部のファイルがエラーになったりする。 短くするにもどう切るとファイル名の意味が損なわれないか個別に考えるのはかなり面倒。 lsじゃなくて、samba等でwindows上のファイラーで見るから 長いファイル名は、一覧では前半しか表示されないけど 個々の名前も見ることが出来るから問題ない >>244 > 例えばタイトルにスラッシュが含まれてたらもう絶対ファイルの名前にできないじゃん。 スラッシュ省くか全角にすればいいだけでは? たった一文字のために、コードで管理する必要ない > そしてファイルマネージャで閲覧したときは,その設定したメタデータが見えるようにできたらよくね? lsもファイルマネージャw >>248 言い争う気はさらさらないのだが 「ファイルの名前に使用できない」という非常に機械的な理由から, タイトルの原題文字列を変更してしまうというのは 俺にはどうしても抵抗があるな。 あとlsじゃなくて例えばxlsみたいなコマンド作ってファイルの属性表示させればよくね? お互い折れる気のない人が議論してもなんのためにもならんでしょ そういう考えの人も居るのか、でスルーすりゃいいのに 例えば ChMate、旧2chMateは、ファイル名にスレッドのタイトルを利用する (この仕様と末尾にTABをつける謎仕様のせいで、 外部SDにそのままアーカイブ出来ないという事態が発生したが、それはまた別の話) スレタイはもちろん文字数制限があるので、全角100文字前後までに普通は収まるが 外部板なども今後も絶対大丈夫などということはなく 仮に全角100文字までとなると、SJISやNTFSのUnicodeならば問題ないが UTF-8等だと問題が出てくるケースがあるかもしれない 全角150字までとなると、SJISでも255バイトを超えかねない (5chのサーバー本体はそんなファイルは作らないので、タイトルの最大文字数を増やすこと自体は簡単) ※「全角」は、datが内部的にSJISで記録されていることからも、用語として妥当 NTFSでファイル名の長さが問題になることがあまりないのは 制限があるのが「バイト数」ではなく「文字数」であるため 一方、一部のファイルシステムでの制限は「バイト数」であるため、文字コードによっては Windows上の制限を大きく下回り、ファイル鯖として使いにくくなってしまう 「自分で使う」ファイルなら、それに合わせたファイル名をつければいいが Excelで作った文書を保存するねーちゃんが、あとでどれほど見やすさ探しやすさを求めて どんなファイル名をつけるかなんて、普通は干渉できない なお、Windows上の制限は、ファイル名についてはそれほど厳しくないが 最大パス長の制限は厳しいので 実際にはそこまで無茶なファイル名が使われることはあまりない ファイルシステムじゃなくてクソアプリが原因の事例出して何いってんだ エリートユーザー様しか使わせないファイルシステム様のスレッドだったか じゃあ俺は場違いだな さようなら 更にいうとパーティションの暗号化をすると ファイル名の制限がキツくなるという謎仕様もある 文字数制限は緩いほうが良いけど文字数の為に使うファイルシステム自体を変えようとは思わないな ディストリの変更とかファイルシステムの変更と比べたら簡単だからな ファイルシステムの変更のほうが簡単では? データコピーするだけでしょ? ファイル名の長短でファイルのサイズは変わらないから 保存容量を減らさずに文章を書き続けられるってことじゃね?? CP932なWindowsからutf-8なLinuxにファイルを持ってきたらさらに文字制限がきつくなる Windowsは全角チルダと波ダッシュの文字化け問題を引き起こす不完全OS Oracleが起動したままxfsをアンマウントしたら、データファイルが全部綺麗に消えました lost+foundにもありません… ufsの頃にはこんなことは何度かありましたが、いまどきのジャーナリングファイルシステムで同じことが起きるとは思ってなかったので驚いてます よくあることなのでしょうか? 前提で????ってなるけど他のファイルシステムで試してみたんか? 旧時代のファイルシステム「EXOFS」メインラインでのサポート終了へ Linux Daily Topics 2018年11月14日 階戸アキラ https://gihyo.jp/admin/clip/01/linux_dt/201811/14 よくよく聞いてみると、どうやらテストの過程で何を間違えたかrmでデータファイルを消したようです ディレクトリは消えてなかったのでおかしいなぁ、と思ったのですが、まさかそんなオペミスするなんて… xfsにあらぬ疑いかけてすまんかった 25年前に「魅入られた様に」にrootアカウントで「rm -r /」を実行したっけ… ある客が /root の中身が消えたというので話を聞いてみると、残ってるデータとかからして、 rm -fr /foo/work/* って実行しようとして、 rm -fr /foo/work/ * を(多分)実行したってのがあったなぁ。 遠因系トラブルで原因はまだ不明らしい。 リンク先みる限り、SSDやNVMe、HDDでも出てて再現できる人は再現 できてるが、できない人はどうやっても再現できない。 VMで再現できた人はいなさそう。 4.18 では問題でないが 4.19 では出るけど、基本的に ext4 周りの修正は 4.18 にバックポートされているので ext4 モジュール以外のところがトリガーだけど、それがどこかわからないという状態みたいね。 4.19.5で不具合出なかったけど4.18.20に戻した kernel.orgのchagelog見た感じでは4.18.20と4.19.3でext4のfixだったから 慌てて4.19.2 → 4.18.20コンパイルじゃなく4.19.2 → 4.19.3にすれば良かったというオチだた 4.19.5でも起きてるってコメントもあるんだけどなあ BLK-MQは有効にしてたけど現象でなかったんだよなあ デバドラレベルのBUSYステータス発生なんて珍しい状態じゃないだろうし FreeBSD ZFS File-System Code To Be Re-Based Over ZFS On Linux https://www.phoronix.com/scan.php?page=news_item& ;px=FreeBSD-ZFS-On-Linux まるでLinuxのZFSが本家みたいになるな Solarisとかほぼ死んでるし まじか 最近追いかけてなかったけどそんなことになってたのか 殺人犯が作った「ReiserFS」使ってる人いる? ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.0 2024/04/24 Walang Kapalit ★ | Donguri System Team 5ちゃんねる