アカウント名:
パスワード:
それでその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
まっさかーこの10数年はLinux界隈もstableがβテストでございますよ
少なくともUbuntuとDebianでは十分痛い目にあっとります
# source.listにはstableではなくバージョン名記載が鉄則
登場当初さんざん非難されましたが、systemdのせいで痛い目をみたって事例はないんですかね?#systemdを理由にDebianからFreeBSDに乗り換えた個人ユーザーなのでAC
俺の経験したのだと debianのapt upgradeで、ブートしなくなるというケースはあった。systemd更新で fstabにNFSのマウント書いても無視するようになったの知らんで、そのままにしてた。(/ と /boot、/etc以外は全部 NFSの構成)
原因わかればたいした問題じゃなかったのだが、バックアップからの復元しても upgradeすると死ぬ。新規インストールしても同じ構成だから当然死ぬ。fstabに書けなくなったという情報が入るまでは、本当に困った。systemd の問題というか、debianのアップグレードポリシー(apt upgradeで、致命的な変更も普通にやっちゃう。パッケージ個別のReleaseNote更みないと変更点はわからない)の問題だが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
いつまでも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: (スコア:0)
まっさかー
この10数年はLinux界隈も
stableがβテストでございますよ
少なくとも
UbuntuとDebianでは
十分痛い目にあっとります
# source.listにはstableではなくバージョン名記載が鉄則
systemdは脱experimentalしたのか?(オフトピ (スコア:0)
登場当初さんざん非難されましたが、systemdのせいで痛い目をみたって事例はないんですかね?
#systemdを理由にDebianからFreeBSDに乗り換えた個人ユーザーなのでAC
Re:systemdは脱experimentalしたのか?(オフトピ (スコア:0)
俺の経験したのだと debianのapt upgradeで、ブートしなくなるというケースはあった。
systemd更新で fstabにNFSのマウント書いても無視するようになったの知らんで、そのままにしてた。(/ と /boot、/etc以外は全部 NFSの構成)
原因わかればたいした問題じゃなかったのだが、バックアップからの復元しても upgradeすると死ぬ。新規インストールしても同じ構成だから当然死ぬ。
fstabに書けなくなったという情報が入るまでは、本当に困った。
systemd の問題というか、debianのアップグレードポリシー(apt upgradeで、致命的な変更も普通にやっちゃう。パッケージ個別のReleaseNote更みないと変更点はわからない)の問題だが。