アカウント名:
パスワード:
それでそのbigtime有効でマウントしてatime更新なんかがされてしまったファイルシステムをbigtime無効な環境で再びマウントしてしまったら一体どうなってしまうんです？
inline_data付きで作成したext4から不用意にinline_dataオプションを取り去ってしまった時のような悲劇的結末が待っているんじゃないんですかねぇ。ましてやXFSなんでファイルシステムの大きさによってはxfs_checkやxfs_repairがメモリ食いすぎで詰んでしまうんじゃ？
ext4は5.4.0の時点で勝手に、ext4 filesystem being mounted at /mnt/hogehoge supports timestamps until 2038
蓄積データ側の変更コストが高いのね始めに非リニアなカウンタにしとけばよかったのかも上位3ビットを精度フラグにして後半は5秒、30秒、1分刻みにするみたいなの非リニアは用途的にヤベーと言うことで汎用に使われる事態も防げたかもしれんし
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
いつまでもexperimentalですねわかります (スコア:0)
それでそのbigtime有効でマウントしてatime更新なんかがされてしまったファイルシステムを
bigtime無効な環境で再びマウントしてしまったら一体どうなってしまうんです？
inline_data付きで作成したext4から不用意にinline_dataオプションを取り去ってしまった時のような悲劇的結末が待っているんじゃないんですかねぇ。
ましてやXFSなんでファイルシステムの大きさによってはxfs_checkやxfs_repairがメモリ食いすぎで詰んでしまうんじゃ？
ext4は5.4.0の時点で勝手に、ext4 filesystem being mounted at /mnt/hogehoge supports timestamps until 2038
Re:いつまでもexperimentalですねわかります (スコア:1)
蓄積データ側の変更コストが高いのね
始めに非リニアなカウンタにしとけばよかったのかも
上位3ビットを精度フラグにして後半は5秒、30秒、1分刻みにするみたいなの
非リニアは用途的にヤベーと言うことで汎用に使われる事態も防げたかもしれんし