サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
都知事選
oeob.sakura.ne.jp
以前書かせていただいた記事はいろんな所でいろんな受け取り方をされたようだ。多少の誤解もあるにせよ、きちんと自分が使っている記憶装置の理解をして、保守をして、バックアップを取ってくださるという方がわずかながらも増えたのであれば喜ばしい。記事の中ではわかりやすくするために多少の誤解を覚悟の上ではしょったところもある。今回は、少しばかり掘り下げてみたいとおもう。 ディスクの壊れ方の分類前回お話しさせて頂いた記事で私が勝手に命名した「半故障」という言葉を使わせていただいた。 「半故障」の定義は、「ドライブの内部で再試行をした結果うまくいってしまい、その時点では障害にならない」状態を言う。例をひとつ挙げると、「書き込み中メディアエラーが発生したが、代替トラックや代替セクターに書き込んだ際にうまくいったので、該当のコマンドは正常終了した」という状態である。[1]インターフェースとして SATA と S
本記事を書こうと思ったのは Twitter で @ogawa_tter さんと会話させて頂いたことがきっかけだ。当たり前に使っているハードディスクや SSD、意外とみなさん誤解されているのではないか?そんなことを思ったので、一つ書かせて頂こうと思う。題して、「あなたのデータが消えるとき」である。 はじまりは一つの警告だったある日あなたはスマートフォンに警告のメールを受け取る。
前回、前々回と NFS と SMB の環境のお話を書かせて頂いた。当然の疑問として、一体に何をどう気をつけたらトラブルが防げるか、というお話を疑問にもたれると思う。今回は、一般的な NFS と SMB での注意点を書かせて頂き、その後、ZFSSA ならではの管理項目上の注意点などを書かせて頂ければと思う。例によって、私なりのメモである。 注意点1:必要もないのに NFS と SMB の複数プロトコルで同じ共有/share を使わない。当たり前の話しと言えば当たり前の話しだが、全クライアントが NFS を使えるのに、わざわざ SMB を混在したり、逆に SMB で大丈夫なのに、NFS を使うクライアントを混在する必要はない。混在をすると、以下に示すが、ロックの問題から始まって、IDマッピングまで設定する羽目になる。 弊社製品も含めて世間の NAS とかアプライアンスと言われる製品の中には、S
今回はロックを通して、SMB/NFS のプロトコルを眺めてみることにする。 1. ロックはなぜ必要か?そもそもなぜロックが必要かと言えば、排他制御のためである。複数のアプリケーションやクライアントから同じファイルを操作していた場合、書き込み(場合によっては読みだしも)ある瞬間特定のアプリケーションやクライアントが他に邪魔されることなくその操作を行えることが必要となってくる。このため、何らかの仕組みを用いてこれを保証することが必要になってくる。この仕組みの一つとして「ロック」が存在する。排他制御をきちんとやることによってデータの予期せぬ破壊や古いデータに基づいてアプリケーションが動いたりすることを防ぐことができる。 ロックの種類は大きく分けて 2 種類あり、強制的なロック (mondatory lock) とアドバイザリーロック(advisory lock)というものが存在する。前者はロック
旬のネタを書くのはある意味その記事の寿命を縮めてしまうので多少ちゅうちょする。もちろん、興味がないことを書いても読んでいただけないので、統計なども取っている。どうやら iSCSI について情報を探している方もいらっしゃるようだ。ここ何日かの傾向であって、もしかしたら全訪問者の 2% くらいの人に向かって書いているかもしれないけれども、一度多くある iSCSI の用語について書くのも良いかと思った。そういった訳で、今回は iSCSI の命名規則について書こうと思う。 1. IQN と EUIiSCSI のイニシエータなどを指し示すのに、2 種類の命名規則がある。一つは IQN (iSCSI Qualified Name) といい、もう一つは EUI (Extended Unique Identifier) という。それぞれ、iqn. あるいは eui. で始まる。以前、「iSCSI を巡るよ
このページを最初にブックマークしてみませんか?
『oeob.sakura.ne.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く