アカウント名:
パスワード:
書き込み中に電源切る使い方なんか他の機器でやらないのにラズパイだと雑になっちゃうのか、そもそも知らないのか
たまたま使いやすいコンセントの場所だったからって掃除のおばちゃんが言ってた
このネタは古くからあるが、最近は掃除でコンセントを勝手に抜くなんてことなくね？今はトラブルの元になるから清掃事業者もその辺り口酸っぱくして教育してるしそもそもまともな事業者なら電源抜いたらまずいところに掃除のおばちゃんは入れないよ。
誰が掃除するの? ホコリがたまったりしたらそれはそれで故障の原因になりそうだけど
掃除用に指定されているコンセントを社員がそうと知らずに使っているケースもあったりする
そもそも知らないのか
これに尽きる。組み込み機器の宿命だね。
再起動は復活する魔法だから、調子が悪い(ネットワークが原因)からと電源強制OFF(運悪く書き込み中)されるとか。営業終了後はブレーカーでぶち切りされるとか。
パソコンでなく、照明みたいな意識になるのかもしれない。照明をリモコンでオフにしてから、壁スイッチをオフにするみたいな面倒臭さ感。
まともな組み込み系ならクリティカルな部分のストレージへの書き込みは二重化しといて訂正符号で書き込み正常にできたかを次回起動時に確認する物では
#ラズパイがまともな組み込み系ボードじゃないと言われればそうなんだけど
『データ書き込み中の電源のぶつ切り』に対して、
クリティカルな部分のストレージへの書き込みは二重化しといて訂正符号で書き込み正常にできたかを次回起動時に確認
は、筋が悪そう。
領域Aと領域B（同容量）に対して・領域Aにデータと訂正符号（CRCとか）を書き込む書き終わったら・領域Bにデータと訂正符号を書き込むまでで完了とした上で、次回起動時にはAとBのそれぞれをチェックして、・両方とも正常ならどちらかをそのまま有効に・両方とも異常ならエラーに・Aの書き込み中に電源がぶつ切りされて書き込み失敗していた場合には一つ前のBを使う・Bの書き込み中に電源がぶつ切りされて書き込み失敗していたらAを使うすれば
『データ書き込み中の電源のぶつ切り』に対して筋が悪そう。
ということもないと思いますが？
バックアップにキャパシタでバックアップしたRAMとかを使っている本当に小規模な組み込みなら常套手段だけど少なくとも1つの領域への完全な書き込み完了を待たないといけないとか、他の問題はあるので規模が大きくなった今の組み込みに対して元コメントがどこまで当たっているかは知らない。
『ファイルシステムのRAM化』なんていうお手本があるのに、それはちょっと的な。システムが壊れない事の話であって、データについては的外れ。
．．．RAM化(原文)で合っているのかなコレ．．．。
全然関係ないよ。
電断が予期される環境でどう書込み値の信頼性を確保するかの話だもの。身近な例だとSUICAとかそんな感じの実装。
microSDだとSDコントローラがどう振る舞うか、ファイルシステムがどう振る舞うかになって、コントロールは簡単ではないと思う。やらないよりは大分マシだけど。SPIフラッシュに設定を保存するなら活用可能かなぁ。
そもそもブート領域(FAT)が飛ぶって話だから、起動時にチェックとかは違う問題じゃね？
筋が悪いとはどこが？
98のデフラグソフトのノストラダムスはそういうメカニズムで安全性を確保していたとういうインタビュー記事を当時読んだことがある。その上でデフラグ中に電源ケーブルを抜くテストを何回もしてデータが壊れないことを確認していたとさ。（DOS上で動くのでファイルシステムはもちろんFAT）
Raspbianで実現するなら、ファイルA/B作ってみたいな感じでいけるかもしれないけど、microSDの内部で書き込み中の電断復帰時にどんな復帰処理がされるかの問題が。この辺がFDDや昔のHDDとFlashメモリデバイスの違う所かな。
最悪、ファイルシステムの一部や管理テーブルがセクタでなく、ブロック単位(4KiBとか8KiB)で吹っ飛んだり化けて、起動不可みたいな事になる。実際起動しなくなってるのが今回の電断テスト事例だしね。
RPiは標準環境だと簡単に出来ないから、SDカードはブート専用でRAM化したりするしかないって話ですね。書き込み可能なストレージをUSBで繋げばどうとでもなる話。
ブート領域がFATなだけ。ext4も特定セクタに書き込みが集中するからSDカード向きじゃない。Paspbianがデフォルトでフラッシュ向けファイルシステム [wikipedia.org]になるだけでもうちょっとマシになると思う。
SDカードはウェアレベリングには対応していないのかな?製品によるとか?
SDカードもウェアレベリングは当然搭載されてます。しかし、基本的に追記書き込みがメイン用途で、安さ重視なので、特定セクターに書き換えが集中するとあっという間に消耗します。また、ext4のようなジャーナリングファイルシステムは、ジャーナルへの書き込みが頻発するので寿命面からは不利です。
製品によるのも確かで、産業用とかはウェアレベリングの予備領域を多めに確保したり、疑似SLC領域にしたりして、書き換えの耐久性を高めています。
書き換え寿命が気になるなら、USB接続のSSD使うのが一番お手軽ですよ。
ウエアレベリングがあるのに特定のセクタに書き込みが集中することなんてあるの？
ジャーナリングが余計なデータ書き込みをするので不利というのは分かるが、それがどこかのセクタに集中したりする？
ストレージ残量に余裕があれば、メモリコントローラが均等にデータをばらまいてくれるもんだと思っていたんだが？
論理セクタです。ext4なら、スーパーブロックやジャーナルで配置されてるセクタです。こいつらが居るセクタは、追記ではなく書き換えが集中します。1バイトの書き換えでも実質4/8KiB(ページ)や512KiB(ブロック)の書き換えが複数回になるのでフラッシュファイルシステムより不利になります。
同じ論理セクターへの書き換えを新しい物理セクターへの(新しい内容での)コピーに置き換えたりするのがウェアレベリングじゃないの? 回答が的はずれすぎる
ウェアレベリングが有っても、無駄に書き換えが発生するので短寿命になると書いています。
まず、書き換えはNANDフラッシュにとって寿命を縮める高コストな処理で有ることは理解していただけると思います。
通常のファイルシステムは、書き換え回数はIOPSのような性能面以外ではほぼ考慮対象になっていません。1バイトのファイルを作っても、ジャーナル、スーパーブロックの消去を伴う書き換え2回とファイル本体の書込みのように複数の書き換えが発生するのが普通です。これが寿命を無駄に縮めます。
対して、フラッシュファイルシステムは、書き換えがストレージ寿命
LinuxもUnixも知らない向きも使ってるからなぁ。自分でもshutdwonしたつもりになってたりするし。
USBブート可能なのは知ってるけど、システムとデータを分けて、システムを戻しやすいのでmicroSD+USBで使ってます。ブートローダのUSBブート対応が遅いことがあるのもネックかも。# USBブートが4Bでついにデフォルトになったのは目出度い。
USB外付けSSDだけど、変換チップが対応してればTRIM出来るよ。 [archlinux.org]駄目でもTRIM送出部分を変換チップにあわせて細工すればよし。RPiでTRIMしないと困るような用途はあまり思い浮かばないけど。
> 書き込み回数が問題なのだから…1時間1回くらいに変更すればいいだけ
原因認識も対処方法も間違ってるような…？
関係ないけど、電源「ぶつ切り」ってのは割と初めて聞いたかも
「電源ブチ切り」が登録商標だから言い換えたのかも。https://www.j-platpat.inpit.go... [inpit.go.jp]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
何だってそうだけどな (スコア:0)
書き込み中に電源切る使い方なんか他の機器でやらないのに
ラズパイだと雑になっちゃうのか、そもそも知らないのか
Re:何だってそうだけどな (スコア:2, すばらしい洞察)
たまたま使いやすいコンセントの場所だったから
って掃除のおばちゃんが言ってた
Re: (スコア:0)
このネタは古くからあるが、最近は掃除でコンセントを勝手に抜くなんてことなくね？
今はトラブルの元になるから清掃事業者もその辺り口酸っぱくして教育してるし
そもそもまともな事業者なら電源抜いたらまずいところに掃除のおばちゃんは入れないよ。
Re: (スコア:0)
誰が掃除するの? ホコリがたまったりしたらそれはそれで故障の原因になりそうだけど
Re: (スコア:0)
掃除用に指定されているコンセントを社員がそうと知らずに使っているケースもあったりする
Re: (スコア:0)
そもそも知らないのか
これに尽きる。組み込み機器の宿命だね。
再起動は復活する魔法だから、調子が悪い(ネットワークが原因)からと電源強制OFF(運悪く書き込み中)されるとか。
営業終了後はブレーカーでぶち切りされるとか。
パソコンでなく、照明みたいな意識になるのかもしれない。
照明をリモコンでオフにしてから、壁スイッチをオフにするみたいな面倒臭さ感。
Re: (スコア:0)
まともな組み込み系ならクリティカルな部分のストレージへの書き込みは二重化しといて訂正符号で書き込み正常にできたかを次回起動時に確認する物では
#ラズパイがまともな組み込み系ボードじゃないと言われればそうなんだけど
Re:何だってそうだけどな (スコア:2)
『データ書き込み中の電源のぶつ切り』に対して、
は、筋が悪そう。
Re: (スコア:0)
領域Aと領域B（同容量）に対して
・領域Aにデータと訂正符号（CRCとか）を書き込む
書き終わったら
・領域Bにデータと訂正符号を書き込む
までで完了とした上で、次回起動時にはAとBのそれぞれをチェックして、
・両方とも正常ならどちらかをそのまま有効に
・両方とも異常ならエラーに
・Aの書き込み中に電源がぶつ切りされて書き込み失敗していた場合には一つ前のBを使う
・Bの書き込み中に電源がぶつ切りされて書き込み失敗していたらAを使う
すれば
ということもないと思いますが？
バックアップにキャパシタでバックアップしたRAMとかを使っている本当に小規模な組み込みなら常套手段だけど
少なくとも1つの領域への完全な書き込み完了を待たないといけないとか、他の問題はあるので
規模が大きくなった今の組み込みに対して元コメントがどこまで当たっているかは知らない。
Re:何だってそうだけどな (スコア:2)
『ファイルシステムのRAM化』なんていうお手本があるのに、それはちょっと的な。
システムが壊れない事の話であって、データについては的外れ。
Re:何だってそうだけどな (スコア:2)
．．．RAM化(原文)で合っているのかなコレ．．．。
Re: (スコア:0)
全然関係ないよ。
電断が予期される環境でどう書込み値の信頼性を確保するかの話だもの。
身近な例だとSUICAとかそんな感じの実装。
microSDだとSDコントローラがどう振る舞うか、ファイルシステムがどう振る舞うかになって、コントロールは簡単ではないと思う。
やらないよりは大分マシだけど。
SPIフラッシュに設定を保存するなら活用可能かなぁ。
Re: (スコア:0)
そもそもブート領域(FAT)が飛ぶって話だから、起動時にチェックとかは違う問題じゃね？
Re: (スコア:0)
筋が悪いとはどこが？
98のデフラグソフトのノストラダムスはそういうメカニズムで安全性を確保していたとういう
インタビュー記事を当時読んだことがある。
その上でデフラグ中に電源ケーブルを抜くテストを何回もしてデータが壊れないことを確認していたとさ。
（DOS上で動くのでファイルシステムはもちろんFAT）
Re: (スコア:0)
Raspbianで実現するなら、ファイルA/B作ってみたいな感じでいけるかもしれないけど、
microSDの内部で書き込み中の電断復帰時にどんな復帰処理がされるかの問題が。
この辺がFDDや昔のHDDとFlashメモリデバイスの違う所かな。
最悪、ファイルシステムの一部や管理テーブルがセクタでなく、ブロック単位(4KiBとか8KiB)で吹っ飛んだり化けて、起動不可みたいな事になる。
実際起動しなくなってるのが今回の電断テスト事例だしね。
Re: (スコア:0)
RPiは標準環境だと簡単に出来ないから、SDカードはブート専用でRAM化したりするしかないって話ですね。
書き込み可能なストレージをUSBで繋げばどうとでもなる話。
Re: (スコア:0)
いつまでFATなんだろう
ジャーナルがあるext4とかじゃダメなのかね
SDカードの壊れ方次第じゃそれでもダメなんだろうけど
Re:何だってそうだけどな (スコア:2, 参考になる)
ブート領域がFATなだけ。
ext4も特定セクタに書き込みが集中するからSDカード向きじゃない。
Paspbianがデフォルトでフラッシュ向けファイルシステム [wikipedia.org]になるだけでもうちょっとマシになると思う。
Re: (スコア:0)
SDカードはウェアレベリングには対応していないのかな?
製品によるとか?
Re:何だってそうだけどな (スコア:1)
SDカードもウェアレベリングは当然搭載されてます。
しかし、基本的に追記書き込みがメイン用途で、安さ重視なので、特定セクターに書き換えが集中するとあっという間に消耗します。
また、ext4のようなジャーナリングファイルシステムは、ジャーナルへの書き込みが頻発するので寿命面からは不利です。
製品によるのも確かで、産業用とかはウェアレベリングの予備領域を多めに確保したり、疑似SLC領域にしたりして、書き換えの耐久性を高めています。
書き換え寿命が気になるなら、USB接続のSSD使うのが一番お手軽ですよ。
Re: (スコア:0)
ウエアレベリングがあるのに特定のセクタに書き込みが集中することなんてあるの？
ジャーナリングが余計なデータ書き込みをするので不利というのは分かるが、それがどこかのセクタに集中したりする？
ストレージ残量に余裕があれば、メモリコントローラが均等にデータをばらまいてくれるもんだと思っていたんだが？
Re: (スコア:0)
ウエアレベリングがあるのに特定のセクタに書き込みが集中することなんてあるの？
論理セクタです。
ext4なら、スーパーブロックやジャーナルで配置されてるセクタです。
こいつらが居るセクタは、追記ではなく書き換えが集中します。
1バイトの書き換えでも実質4/8KiB(ページ)や512KiB(ブロック)の書き換えが複数回になるのでフラッシュファイルシステムより不利になります。
Re: (スコア:0)
同じ論理セクターへの書き換えを新しい物理セクターへの(新しい内容での)コピーに置き換えたりするのがウェアレベリングじゃないの? 回答が的はずれすぎる
Re: (スコア:0)
ウェアレベリングが有っても、無駄に書き換えが発生するので短寿命になると書いています。
まず、書き換えはNANDフラッシュにとって寿命を縮める高コストな処理で有ることは理解していただけると思います。
通常のファイルシステムは、書き換え回数はIOPSのような性能面以外ではほぼ考慮対象になっていません。
1バイトのファイルを作っても、ジャーナル、スーパーブロックの消去を伴う書き換え2回とファイル本体の書込みのように複数の書き換えが発生するのが普通です。
これが寿命を無駄に縮めます。
対して、フラッシュファイルシステムは、書き換えがストレージ寿命
Re: (スコア:0)
LinuxもUnixも知らない向きも使ってるからなぁ。
自分でもshutdwonしたつもりになってたりするし。
Re:何だってそうだけどな (スコア:1)
USBブート可能なのは知ってるけど、システムとデータを分けて、システムを戻しやすいのでmicroSD+USBで使ってます。
ブートローダのUSBブート対応が遅いことがあるのもネックかも。
# USBブートが4Bでついにデフォルトになったのは目出度い。
USB外付けSSDだけど、変換チップが対応してればTRIM出来るよ。 [archlinux.org]
駄目でもTRIM送出部分を変換チップにあわせて細工すればよし。
RPiでTRIMしないと困るような用途はあまり思い浮かばないけど。
Re: (スコア:0)
> 書き込み回数が問題なのだから…1時間1回くらいに変更すればいいだけ
原因認識も対処方法も間違ってるような…？
Re: (スコア:0)
関係ないけど、電源「ぶつ切り」ってのは割と初めて聞いたかも
Re:何だってそうだけどな (スコア:2, 興味深い)
「電源ブチ切り」が登録商標だから言い換えたのかも。
https://www.j-platpat.inpit.go... [inpit.go.jp]