Linuxカーネルはx86やx86_64で起動する場合にBIOSが使う可能性がある下位64kBのメモリを触らないようになっているが、一部のイカれたBIOSがOSに何の断りもなく下位1MBまで書き込んでいて、1MB以下にカーネルが何… https://t.co/SQWEaNlCex
Linuxカーネルはx86やx86_64で起動する場合にBIOSが使う可能性がある下位64kBのメモリを触らないようになっているが、一部のイカれたBIOSがOSに何の断りもなく下位1MBまで書き込んでいて、1MB以下にカーネルが何… https://t.co/SQWEaNlCex
セキュリティ対策室の伊藤洋也 @hiboma です。 業務中に、Haconiwa コンテナ で動くとある node プロセスが general protection fault ( 一般保護違反! ) を起こしてdmesg にログを残す現象を調べ、問題解決にあたっていました。その際の痕跡をまとめなおして記したエントリになります。 エントリの概要 本エントリでは、以下のような内容を扱います。 Haconiwa コンテナの node プロセスが general protection fault を起こしている ライブラリ関数 abort(3) の概要 abort(3) がプロセスを停止する方法の検証 node プロセスが abort(3) を呼び出すケース glibc x86系の abort(3) 実装が HLT 命令を呼び出し、general protection fault を起こすこと
先日Linusが盛大にZFSを非難したことがインターネット・カーネル界隈の噂を駆け巡った。これをタイトルだけみたり本文をちょっと読んだら「ああ、LinusはZFSが嫌いなんだ」とか「LinuxでZFSを使うべきではない」といった理解をする人が非常に多いだろうと思う。Linusは当然Linuxユーザーにとって大きな影響力を持つ人物であり、多くのLinuxユーザーがこの理解のままでいることになりかねない。公私ともにZFSに頼りっきりになっている私は特にそういう状況は非常に困るし、Canonicalは19.10からUbuntu LinuxでのZFS rootを標準にしようとしているくらいだからもっと困るだろう。複雑な状況になっていると思うので、このニュースの深層を探ってみよう。 まず元スレ 元になったLinusのレスによると、そもそも最近カーネルにドライバのインターフェース変更があってZFSがこ
TL;DR 聴講メモ Intro into durability PostgreSQLのCHECKPIONT CHECKPOINT中にエラーが発生したら? fsyncへの2つの間違った期待 なぜ今になって問題が明らかになってきた? そもそもなぜBufferd I/Oなのか? どうやって直すかか 参考リンク 質疑 最後に 先日PostgreSQLの新しいマイナーバージョンがリリースされました。このマイナーリリースでメインとなる修正は「fsync周りのバグ修正」で、このバグは間違ったfsyncに対する間違った認識から約20年間存在してたバグということで注目されていました。 このバグについてPostgreSQLのコミッタ(Tomas Vondra氏)が解説しているセッションが、先々週開催されたFOSDEM 2019でありました。私もFOSDEM 2019に参加していたのですがその際は裏セッション
Nebulet is a Google Summer of Code project started during the summer of 2018. More details about Nebulet and GSoC are here. Under the hood, Nebulet is a microkernel that executes WebAssembly modules in ring 0 and a single address space to increase performance. This allows for low context-switch overhead, syscalls just being function calls, and exotic optimizations that simply would not be possible
はじめに こんにちは、技術顧問のsatです。 サイボウズでは、ファイルシステムサイズ拡張時にデータベースアクセスがスローダウンするという問題に長年悩まされてきました。本記事では運用本部の藤田と深谷がこの問題を解決した流れについて報告いたします。問題を解決するために2人はLinuxカーネルを修正しました。修正は社内に閉じたものではなく、執筆当時の最新 Linuxカーネルであるv4.17にマージされています。 問題 以下の操作の後にデータベースへのアクセスが一時的にスローダウンする ブロックデバイスのサイズを拡張する 上記デバイス上にあるファイルシステムのサイズを拡張する 原因 linuxカーネルはブロックデバイスのサイズ変更(縮小および拡張)時に、当該デバイス上にあるファイルシステムのページキャッシュ(後述)を無効化する*1 解決方法 ブロックデバイスのサイズ拡張時にはページキャッシュを無効
Mackerelチームのエンジニアのid:itchynyです。 「mackerel-agentを入れるとloadavgが7時間ごとに上昇する」 先日、このような問い合わせを複数のお客さまから受けました。私も実験してみたところ、確かに再現しました。EC2 t2.microにmackerel-agentを入れて簡単なログ監視とプロセス監視を設定し、数日放置しました。 確かに、約7時間ごとにloadavgが上昇しています。この周期のcronの設定はしておらず、またmackerel-agent内部でも7時間ごとに行う処理はありません。しかし、プラグインを多く入れるほどloadavgのピーク値も上がります。 本エントリーでは、この現象の原因について説明します。 loadavgが上昇する原因を調べるには、まずloadavg自体がどう計算されているかを知る必要があります。 まずは、Linuxがloada
こんにちはサイボウズ・ラボの光成です。 先日(8/23~8/25)、サイボウズ・ラボユース合宿をしたのでその紹介をします。 合宿の概要 サイボウズ・ラボユースは学生のソフトウェア開発を支援する制度で、詳細は「第6期サイボウズ・ラボユース成果発表会」開催などをご参考ください。 合宿の目的は、ラボユース生同士、交流を深めてもらうことです。 今年度はリモート参加の学生も多く、なかなか他の学生と交流しにくいだろうという背景があり、久しぶりの開催となりました。 もちろん集中的に開発し、様々な疑問をまとめて聞ける場を提供するのも大きな目的の一つです。 合宿の参加者は現役のラボユース生が4名、研究生が1名、ラボユースOBが4名、ラボからは7名で、 会場は神奈川県三浦海岸のマホロバ・マインズ三浦でした。 男性参加者は3~4人一組で泊まるのですが、部屋が約100平方メートル3LDKとかなりの広さで快適でした
Tweet お知らせ - 2018.02.22 Linux カーネルはメモリが枯渇した際の挙動を十分に考慮しておらず、メモリの枯渇が原因でLinux システムがハングアップしてしまうことがあるという問題があります。 この問題に当社ソリューション事業部 半田 哲夫が4年半取り組み続けた結果、メモリの枯渇時にハングアップしてしまう処理の多くが修正されました。現時点までの道のりは、以下の資料/動画でご覧いただけます。 資料:https://elinux.org/images/7/73/CELFJP-Jamboree63-handa-ja.pdf(社外サイト) 動画:https://youtu.be/ZznEyf1PN0Q(社外サイト)
このエントリは KLab Advent Calendar 2017(兼 mruby Advent Calendar 2017)の 12 日目の記事です。 今年は(前半は)Keepalived にフルタイムでコントリビュートしていたり(後半は)ひたすら mruby をいじっていたりと、実に OSS 充な一年だった @pandax381 です。 タイトルにある試みについては、2015 年の時点で東京大学の品川先生が「mruby を Linux カーネル内で動作させる」という素晴らしい記事を書かれていて、Kernel module に組み込んだ mruby が動作することを実証されています。 mruby をカーネル内で動作させるために大きく問題となるのが、浮動小数点演算です。mruby は Float を標準的なクラスとして提供していると共に VM 内部でも浮動小数点演算を行っている一方で、Ke
textlint 9.0.0をリリースしました。 textlint 9.0.0では@textlint/kernelという内部的に使うコアモジュールをTypeScriptで書き直したバージョンが使われています。 元々textlintはNode.jsで動くように作られたため、fsモジュールなどNode.jsに依存しています。 そのため、ブラウザなどで動かす場合などはビルド時に色々工夫しないと動きません。 文書校正ツール textlint の Chrome 拡張を作った - もなでぃっく LocalStorageで誰でも安全にMarkdownでスライドやメモ作れるサービス作ったよ この問題をどうにかするためには、textlintというモジュールからロジックやLint処理部分だけをNode.jsなどに依存しない純粋なJavaScriptとして切り出す必要があります。 アドホックに対応するならブラウ
挿入削除機能付きファイルシステム 概要 現在のパーソナルコンピュータでサポートされている汎用的なファイルシステムでは、ファイルへの操作は、読み出し(read), 書き込み(write), シーク(seek)などのシステムコールにより行われています。そのため、映像などの大きなサイズのファイルの一部分のデータに対して挿入や削除を行いたい場合、それ以降のデータに対してもコピー動作が必要となるため、操作の完了までに時間がかかるという問題があります。 挿入削除機能付きファイルシステムは、ファイルに対する挿入および削除を高速に行うことを目的に開発したファイルシステムです。挿入削除機能付きファイルシステムは次の操作を高速に行うことができます。 ファイルに対するブロックの挿入 ファイルに対するブロック単位の削除 ファイルの一部分のブロックを他のファイルへ移動 ブロックのサイズはデフォルトでは4Kバイトにな
なんかスラドにあげられてしまったので、備忘録てきにちょっとまとめますかね。 きっかけは先月帰国したときに sonots がDeNAをはじめとして、Web企業では広く TCP_TIMEWAIT_LEN を変更してカーネルをリコンパイルして使っているという話を聞いたというもの。以下の様な議論を twitterで行い Togetter: Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味?: http://togetter.com/li/871768 以下のように、スラドに転載されてしまったわけだ。 スラド: Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味?: http://linux.srad.jp/story/15/09/09/0648258/ いつものように、スラド民は元のスレッドなんかまるで読んでいないので、結論だけ書く。 tcp_tw_inter
Linuxカーネルのメーリングリストは、常に罵詈雑言に満ち溢れているが、そういうのは辞めて大人になろうという主張がSarah Sharp[1]によってなされた。なかなか面白い。 きっかけは、いたって日常的な罵倒混じりの議論に、Sarah Sharpが横槍を入れたところから始まった。 LKML: Sarah Sharp: Re: [ 00/19] 3.10.1-stable review On Fri, 12 Jul 2013 18:17:08 +0200, Ingo Molnar <mingo@kernel.org> wrote: * Linus Torvalds <torvalds@linux-foundation.org> wrote: On Fri, Jul 12, 2013 at 8:47 AM, Steven Rostedt <rostedt@goodmis.org> wrote
昨日、TOMOYO Linuxメインライン化記念合同勉強会(カーネル読書会、セキュアOSユーザ会、まっちゃ445)に行ってきて、小崎さんが匿名掲示板でガチでレビューしていたお話を聞いたので、早速過去ログを読んでみた。http://tomoyo.sourceforge.jp/2ch/thread-2.txt (追記:2009/7/4 21:03 なぜか後半部分、アスキーアートの後が切れてしまったので、前半部分を若干カットして(略)の部分、その2を追加しました。) LKML (Linux Kernel Mailing List)というのはLinuxカーネルの技術的なことを議論するもっとも権威(?)あるメーリングリストで、ここで議論され合意されたものがLinuxの本体に取り込まれることになる。このLinuxの本家本元の本体(くどいな)のことをメインラインと呼ぶ。Linuxを創ったLinusさんに
更新履歴 2012-08-28: URL 公開 2012-08-29: futex、hrtimer、MySQL の発生条件、NTP SLEW モードに関する @odhrfm さんからの情報、キーワード更新、その他いろいろ細かい修正 2012-08-30: 参考リンク追加 2012-09-01: LKML まとめシートの thread#50 を追加 2012-09-03: SLES カーネルの更新情報、per-cpu についての記述、blockdiag によるブロック図を追加 2012-09-11: LKML まとめシートの thread#52, #53 を追加 2012-09-12: LKML まとめシートの thread#54 〜 #58 を追加 はじめに 日本時間 2012 年 7 月 1 日 9:00 にうるう秒が挿入されましたが、その際 Linux カーネルに起因する不具合により、
サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第18回(これまでの連載一覧)。サイボウズ・ラボの光成 滋生さんにお話を伺うシリーズ(1)です。 本連載は、「WEB+DB PRESS Vol.80」(2014年4月24日発売)に掲載された「エンジニアの学び方──効率的に知識を得て,成果に結び付ける」の続編です。(編集部) 文:西尾 泰和 イラスト:歌工房 この連載では「エンジニアの学び方」をテーマにインタビューを行い、どういう「学び方」をしているのか探求していきたいと思っています。第2弾は、サイボウズ・ラボのエンジニアとして、楕円曲線などの難しい数学を使った暗号の論文を読んで実装したり、サイボウズが遭遇した問題の原因を掘り下げていって最終的にLinuxのバグを修正したり、と幅広い活動をされている光成滋生さんです。 光成さんが、どういうプロセスで問題の原因を
systemdは、/proc/cmdlineをパースして、もし、その中に"debug"という文字列を発見した場合、大量の冗長なデバッグメッセージをdmsegに出力する。これは様々な問題を引き起こす。まず、"debug"というあまりに一般的すぎる文字列に勝手に反応してしまうことがひとつ。dmseg、すなわちカーネルのリングバッファーをsystemdの冗長なデバッグメッセージだけで溢れ返させてしまうことがひとつ。そして、なぜかLinuxカーネルのブートに失敗してしまうことがひとつ。 Bug 76935 – Do not parse "debug" command line parameter カーネルコマンドラインに"debug"を与えると、systemdによりパースされる。適当なassertに引っかかると、こんな風にぶっ放される。 [ 150.308000] systemd-journald
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く