Filesystemに関するnari_exのブックマーク (11)

  • ext3からext4への更新概要

    Kernel Recipes 2017 - Understanding the Linux kernel via ftrace - Steven RostedtAnne Nicolas

    ext3からext4への更新概要
  • EXT4 vs XFS vs Btrfs vs ZFSをfioでベンチマークを取ってみました。 - Qiita

    概要 CentOS7のデフォルトのファイルシステムがXFSとなりました。 mkfsコマンドでも、minix, xfs, btrfsが使えるようになりました。 そこで気になるファイルシステムを色々調べ、ベンチマークを自分なり取ってみました。 多少なりともご参考になればと思います。 色々なファイルシステム こちらをご参考ください。 http://qiita.com/sion_cojp/items/c8e015db39ddbf43012e それぞれファイルシステムを作ってみる 今回の環境は CentOS6(ホスト) 4Core, MEM:32G, HDD:300G CentOS7(ゲスト。こちらで計測しております。) vCPU *1, MEM:4G, HDD:40G 容量が少なかったため、btrfsのベンチマークが終わった後、zfsにファイルシステムを変更し検証をしております。 ### zfsの

    EXT4 vs XFS vs Btrfs vs ZFSをfioでベンチマークを取ってみました。 - Qiita
  • Btrfsの基礎 part1 機能編

    This document is the basic introduction to Btrfs, the next generation linux file system. It covers Btrfs's basic concept and important features. It contains many figures to make it easy for readers to understand this file system.Read less

    Btrfsの基礎 part1 機能編
  • [SOLVED]Should /boot partition be formated in ext2 or ext4? / Installation / Arch Linux Forums

    You can use anything you like for a separate /boot partition, provided both Linux and your boot loader can read it -- ext2, ext4, XFS, HFS+, FAT, etc. Some of these filesystems do have limitations, though. For instance, since FAT doesn't support symbolic links, you can't do something like link a kernel with a generic name to one with a more specific name. I've seen some configurations that rely on

    nari_ex
    nari_ex 2014/05/11
    /boot をマウントするときのファイルシステムは ext2 と ext4 のどちらが良いのかという議論。/boot は小さいし ext2 で十分だから別にいいじゃん派、ext4 の方が若干速いし高機能だから ext4 でしょ派がいる模様。
  • NVMFS: A hybrid file system for improving random write in nand-flash SSD

    nari_ex
    nari_ex 2014/05/07
    Fusion-ioが開発してるらしいNVMFSを検索してたら、この論文にたどり着いた。
  • 冬の日2014〜ioDriveが壊れた日〜 - FAT47の底辺インフラ議事録

    ある日 ioDriveを積んでるMySQLスレーブサーバが突然の死。 というか、レプリケーションが止まっていました。 サービスから参照されていないDBではあったので、 特に死んでいても問題にはなりませんでした。 今回つかっていたのはioDrive Duoです。 /var/log/messages確認 とりあえずシステムのログを確認してみると、 Jan 27 05:39:36 hoge-dbs kernel: fioinf HP 640GB MLC PCIe ioDrive Duo for ProLiant Servers 0000:09:00.0: groomer read had error -1024 Jan 27 05:39:36 hoge-dbs kernel: fioerr HP 640GB MLC PCIe ioDrive Duo for ProLiant Servers 00

    冬の日2014〜ioDriveが壊れた日〜 - FAT47の底辺インフラ議事録
    nari_ex
    nari_ex 2014/02/05
    パーティション分けておいてよかったですね〜
  • ext4 vs xfs(sysbench fileio) | Ore no homepage

    ちょっとやってみました。まず結論から言うと、今回の検証環境での実験および得られた結果のみから判断すると、ext4とxfsの性能差は特に見られませんでした。IOスケジューラの違いによる性能差は顕著に見られました。デフォのcfqよりはdeadlineやnoopが良いという下馬評(?)の通り、deadline, noopが良かったです。並列数が増えると差が明らかに見えます。ファイルシステムのオプションの差異が見えなかったのはつまらなかったな。noatimeの効果についてしっかり検証した人周囲にあまりいないし(俺も「とりあえず付けとけ」みたいな感じだったし)、もしかしたら大した効果はないのかもしれない(?)。 1. 検証環境 OS:CentOS6.2 ( 2.6.32-220.17.1.el6.x86_64 ) CPU: Intel(R) Xeon(R) CPU E5620 2.40GHz ( H

  • block/cfq-iosched.c in ti-codecs/ti-codecs:master - Gitorious

  • バウンスバッファー - Linuxの備忘録とか・・・(目次へ)

    デバイスブロックとデバイスのやり取りは、bioに設定されているページとDMAで行っています。もしそのページがハイメモリ等の、デバイスとDMAでやり取りできないページだと、元のbioを複製した物に、DMAとやり取りするページを割り当てる事でDMA転送を行います。このbioをバウンスバッファーと言うそうです。新たに作成したbioには、bi_privateメンバーに、元のbioが設定されており、読み込みなら、新たに設定したブロックIO終了コールバック関数で、DMA転送されたデータを、元のbioのページに転送する事になります。 blk_queue_bounce()でバウンスバッファーのbioを作成します。bio_origが元のbioです。bio_empty_barrier()はbioがバリアがどうかチェックします。ブロックレベルのフラッシュみたいなものです。あるブロック群が完全に書き込まれてからで

    nari_ex
    nari_ex 2013/12/16
    バウンスバッファー、初めて知った。
  • ext3とトランザクション処理

    長い利用実績を誇るext2の互換ファイルシステムext3。このファイルシステムにはどのような特徴があるのか? そしてどのようにジャーナリングを実現しているのか? 今回はext3について解説する。(編集局) 今回からext3、ReiserFS、JFS、XFSについて解説する。これらのファイルシステムはそれぞれ独自の方法で高速化、信頼性/可用性向上を実現するために開発が続けられている。高速化や可用性を実現する方法としては、前回までにB*-Tree、エクステント、ダイナミックiノードを紹介した。また、信頼性を達成する技術としてジャーナリング機能の基的な仕組みを解説した。 各ファイルシステムは、それぞれ独自の方法でこれらの技術を取り込んでいる。特にジャーナリング機能は、これから紹介する4ファイルシステムのいずれもが実装している。ただし、ジャーナリングの内容については次の点で違いがある。 ext3

    ext3とトランザクション処理
  • LinuxカーネルHack: Btrfsのコードに散りばめられたBUG_ONマクロが示す兆候 - 佐野デジタル研究所

    BUG_ONマクロは、Linuxカーネルにおいて、引数に与えられた式を評価した結果が真となることが想定されない箇所(つまり、真ならバグ)で使われる。簡単に言うと、Cのassertのようなもの。ただし、assertよりもきつくて、BUG_ONの引数が真になると、カーネルパニックを引き起こす。つまり、BUG_ONの引数が真になったらカーネルが即死なので、利用には十分に気をつけるべきマクロである。 Btrfsのコードを読み始めて薄々感じていたけれども、BtrfsではこのBUG_ONマクロが過剰なまでに多く使われている。 他のファイルシステムと比べて、どの程度過剰か数字を取ってみた。(数字は、最新のメインラインより計測。tail -n +2は、findの結果の1行目にfsが含まれることで、xargs grepで2重に計測してしまうのを防ぐトリック。BUILD_BUG_ONは、無害とみなした。) 枯

    LinuxカーネルHack: Btrfsのコードに散りばめられたBUG_ONマクロが示す兆候 - 佐野デジタル研究所
    nari_ex
    nari_ex 2013/11/29
    なるほどそういうことか
  • 1