实际上，不同版本的Flashcache，输出的性能指标有一些变化。较老的stable_v1版本的性能指标暴露在/proc/flashcache_stats，但是有些重要的指标没有包含进来，例如metadata ssd writes。而新版本支持一个系统中创建多个flashcache设备，因此位置修改成了/proc/flashcache/ssddev+diskdev/flashcache_stats，其中ssddev+diskdev根据实际的设备名不同而不同，例如在上一篇我们创建的模拟设备就应该是loop0+loop1，同时sysctl参数也根据设备名可以设置多组。为了兼容，flashstat针对老版本的flashcache还是解析dmsetup status的信息，而针对新版本则解析/proc中的flashcache_stats。

Flashstat的项目地址为：https://github.com/NinGoo/flashstat，和Mohan讨论过后，他已经将这个小工具接纳并merge到了主干代码，因此现在下载Flashcache的源码，已经在utils目录中包含了这个小工具，希望对Flashcache的用户有点用处。

Flashstat的用法很简单，指定监控时间间隔（-i 默认1s），监控次数（-c 默认0表示一直监控），flashcache设备（-d 默认/dev/mapper/cachedev）即可。如果需要将结果重定向到文件，则建议关闭ANSI颜色显示，使用-n或者–nocolor选项即可。

输出结果：

  read/s                reads per second for cachedev
  write/s               writes per second for cachedev
  diskr/s               disk reads per second
  diskw/s               disk writes per second
  ssdr/s                ssd reads per second
  ssdw/s                ssd writes per second
  uread/s               uncached reads per second
  uwrit/s               uncached writes per second
  metaw/s               metadata ssd writes per second
  clean/s               cleanings per second
  repl/s                replacement per second
  wrepl/s               write replacement per second
  hit%                  read hit percent(current hit%|total hit%)
  whit%                 write hit percent(current whit%|total whit%)
  dwhit%                dirty write hit percent(current dwhit%|total dwhit%)

在前两天的一次测试过程中，发现iostat中disk device的svctm的波动比较大，当时利用flashstat很快定位了波动的原因。测试场景是MySQL的纯读场景，disk device的svctm一般都小于1ms，偶尔会波动到2ms，4ms甚至6ms以上，但没有超过8ms。

首先查看raid卡的cache策略

$sudo /opt/MegaRAID/MegaCli/MegaCli64 -LDGetProp -Cache -LALL -aALL
Adapter 0-VD 0(target id: 0): Cache Policy:WriteBack, ReadAheadNone, Direct, Write Cache OK if bad BBU

所有Raid卡不会缓存读操作，如果读IO透过flashcache落到了disk，那响应时间应该在6ms左右是正常的。而Raid卡会缓存写操作，写的响应时间就会短很多，一般在1ms以内。所以iostat显示的小于1ms的svctm，应该是混合了读写的平均响应时间的结果。但MySQL测试的场景是纯读，只有select，哪里来的写呢？通过flashstat发现clean/s和diskw/s一直持续有较大的值，原来是新版本的flashcache增加了根据脏块的过期时间后台刷出的特性，于是尝试关闭该特性

$sudo sh -c "echo 0 > /proc/sys/dev/flashcache/fioa+sdb1/fallow_delay"

再观察flashstat的结果，发现clean/s, diskw/s变为0，同时iostat -x显示sdb的svctm时间稳定在5ms左右了。也就是说，之前看到的svctm时间不稳定，是由于flashcache后台刷出过期脏块的波动导致的，当刷出写入disk的力度较大时，由于写的响应时间较短（一般在100～200微妙），iostat的读写混合平均响应时间较低，而当写出较少时，iostat的读写混合平均响应时间反而较高了。用数据说话，但如果数据是平均值，则很容易掩盖掉一些瞬间的波动的珍视情况，尽信数据，不如无数据。

另外，利用blkiomon，也可以很好的验证上面的结论。blkiomon可以看到不同大小的io的响应时间的分布，根据blkiomon的输出结果，可以比较方便的分析io的行为，帮助追踪和确认很多的io工具，一大神器。

下面是一个输出的示例，可以看到，1369次读io的平均大小是13k，平均响应时间约5.5ms，而245次写io的平均大小约20k，平均响应时间约203微秒。响应时间分布中，1毫秒以内的io次数有244次（差不多都是写），最快的响应时间只有26微妙。2毫秒以上的有1370次（差不读多都是读），响应最慢的有一次达到35毫秒。

$sudo  mount -t debugfs none /sys/kernel/debug/

$sudo  blktrace /dev/sdb -a issue -a complete -w 3600 -o - | blkiomon -I 5 -h -

time: Fri Jan 13 23:50:43 2012
device: 8,16
sizes read (bytes): num 1369, min 4096, max 16384, sum 18919424, squ 286236082176, avg 13819.9, var 18094812.6
sizes write (bytes): num 245, min 4096, max 131072, sum 5124096, squ 317106159616, avg 20914.7, var 856887118.5
d2c read (usec): num 1369, min 154, max 35396, sum 7526791, squ 51513446469, avg 5498.0, var 7400285.0
d2c write (usec): num 245, min 26, max 9605, sum 49959, squ 238326529, avg 203.9, var 931180.3
throughput read (bytes/msec): num 1369, min 298, max 106389, sum 4275218, squ 28512922538, avg 3122.9, var 11075196.9
throughput write (bytes/msec): num 245, min 2287, max 970903, sum 54430349, squ 24934376050407, avg 222164.7, var 52415814078.9
sizes histogram (bytes):
            0:     0         1024:     0         2048:     0         4096:   217
         8192:   212        16384:  1129        32768:    25        65536:    11
       131072:    20       262144:     0       524288:     0      1048576:     0
      2097152:     0      4194304:     0      8388608:     0    > 8388608:     0
d2c histogram (usec):
            0:     0            8:     0           16:     0           32:     8
           64:    99          128:    61          256:    73          512:     1
         1024:     2         2048:    52         4096:   350         8192:   809
        16384:   151        32768:     7        65536:     1       131072:     0
       262144:     0       524288:     0      1048576:     0      2097152:     0
      4194304:     0      8388608:     0     16777216:     0     33554432:     0
    >33554432:     0
bidirectional requests: 0

参考文章：
[1] Flashcache README
[2] IO模式调查利器blkiomon介绍

您可能也喜欢：
深入浅出Flashcache（一）	Oracle12G将不再支持裸设备？	Windows平台不支持32k的block size	关于Change Data Capture（一）	OOW2009美国行:纽约一日游
无觅

make -j 4 KERNEL_TREE=/usr/src/kernels/2.6.32-131.0.15.el6.x86_64
sudo make install

最初版本的Flashcache只支持writeback，后来单独开了一个支持writethrough的分支在flashcache-wt目录，但目前最新的版本已经将write through合并到主版本，并且增加了write around策略。

最新的源码可以到Github获取。

env GIT_SSL_NO_VERIFY=true git clone https://github.com/facebook/flashcache.git

建议下载完源码后的第一件事，就是去doc下阅读flashcache-doc.txt和flashcache-sa-guide.txt，保证比我则几篇blog有养分得多。

不是每个人都有SSD/PCI-E Flash的硬件，所以这里可以给大家一个构建虚拟混合存储设备的小技巧，这样即使是在自己的笔记本上，也可以轻松的模拟Flashcache的试验环境，而且随便折腾。

首先，我们可以用内存来模拟一个性能很好的Flash设备，当然这有一个缺点，就是主机重启后就啥都没了，不过用于实验测试这应该不是什么大问题。用内存来模拟块设备有两种方法，ramdisk或者tmpfs+loop device。由于ramdisk要调整大小需要修改grub并重启，这里我们用tmpfs来实现。

# 限制tmpfs最大不超过10G，避免耗尽内存(测试机器有24G物理内存)
$sudo mount tmpfs /dev/shm -t tmpfs -o size=10240m
# 创建一个2G的文件，用来模拟2G的flash设备
$dd if=/dev/zero of=/dev/shm/ssd.img bs=1024k count=2048
# 将文件模拟成块设备
$sudo losetup /dev/loop0 /dev/shm/ssd.img

解决了cache设备，还需要有disk持久设备。同样的，可使用普通磁盘上的文件来虚拟成一个loop device。

# 在普通磁盘的文件系统中创建一个4G的文件，用来模拟4G的disk设备
$dd if=/dev/zero of=/u01/jiangfeng/disk.img bs=1024k count=4096
$sudo losetup /dev/loop1 /u01/jiangfeng/disk.img

这样我们就有了一个快速的设备/dev/loop0，一个慢速的磁盘设备/dev/loop1，可以开始创建一个Flashcache混合存储设备了。

$sudo flashcache_create -p back cachedev /dev/loop0 /dev/loop1
cachedev cachedev, ssd_devname /dev/loop0, disk_devname /dev/loop1 cache mode WRITE_BACK
block_size 8, md_block_size 8, cache_size 0
Flashcache metadata will use 8MB of your 48384MB main memory

$sudo mkfs.ext3 /dev/mapper/cachedev
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
262144 inodes, 1048576 blocks
52428 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1073741824
32 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

$sudo mount /dev/mapper/cachedev /u03

Ok，检查一下，就可以开始做一些模拟测试啦。

$sudo dmsetup table
cachedev: 0 8388608 flashcache conf:
        ssd dev (/dev/loop0), disk dev (/dev/loop1) cache mode(WRITE_BACK)
        capacity(2038M), associativity(512), data block size(4K) metadata block size(4096b)
        skip sequential thresh(0K)
        total blocks(521728), cached blocks(83), cache percent(0)
        dirty blocks(0), dirty percent(0)
        nr_queued(0)
Size Hist: 4096:84 

$sudo dmsetup status
cachedev: 0 8388608 flashcache stats:
        reads(84), writes(0)
        read hits(1), read hit percent(1)
        write hits(0) write hit percent(0)
        dirty write hits(0) dirty write hit percent(0)
        replacement(0), write replacement(0)
        write invalidates(0), read invalidates(0)
        pending enqueues(0), pending inval(0)
        metadata dirties(0), metadata cleans(0)
        metadata batch(0) metadata ssd writes(0)
        cleanings(0) fallow cleanings(0)
        no room(0) front merge(0) back merge(0)
        disk reads(83), disk writes(0) ssd reads(1) ssd writes(83)
        uncached reads(0), uncached writes(0), uncached IO requeue(0)
        uncached sequential reads(0), uncached sequential writes(0)
        pid_adds(0), pid_dels(0), pid_drops(0) pid_expiry(0)

$sudo sysctl -a | grep flashcache
dev.flashcache.loop0+loop1.io_latency_hist = 0
dev.flashcache.loop0+loop1.do_sync = 0
dev.flashcache.loop0+loop1.stop_sync = 0
dev.flashcache.loop0+loop1.dirty_thresh_pct = 20
dev.flashcache.loop0+loop1.max_clean_ios_total = 4
dev.flashcache.loop0+loop1.max_clean_ios_set = 2
dev.flashcache.loop0+loop1.do_pid_expiry = 0
dev.flashcache.loop0+loop1.max_pids = 100
dev.flashcache.loop0+loop1.pid_expiry_secs = 60
dev.flashcache.loop0+loop1.reclaim_policy = 0
dev.flashcache.loop0+loop1.zero_stats = 0
dev.flashcache.loop0+loop1.fast_remove = 0
dev.flashcache.loop0+loop1.cache_all = 1
dev.flashcache.loop0+loop1.fallow_clean_speed = 2
dev.flashcache.loop0+loop1.fallow_delay = 900
dev.flashcache.loop0+loop1.skip_seq_thresh_kb = 0

参考文档：
[1] Flashcace安装 How-to
[2] Flashcache中文简介——Linux上的回写块缓存
[3] tmpfs from wikipedia
[4] loop device from wikipedia

您可能也喜欢：
深入浅出Flashcache（一）	Oracle12G将不再支持裸设备？	在Redhat Entrerprise Linux 5上安装Oracle11g截图欣赏	东南亚之旅：越南与柬埔寨（二）	关于Oracle Companion CD
无觅

Linux内核支持动态的加载模块（Loadable Kernel Module，LKM）以完成某些特定的功能，模块编程需要按照一定的格式以便可以和内核交互。

5. 内核符号表

内核模块之间的交互需要通过特定的共享变量和函数，这些都需要输出到内核符号表。在模块编程中使用EXPORT_SYMBOL来进行定义。在内核中则使用了kernel_symbol结构来保存符号表信息。

# 内核编程基本上都需要包含如下三个头文件。
#include<linux/kernel.h>
#include<linux/module.h>
#include<linux/init.h>

#内核符号表结构体
struct kernel_symbol
{
    unsigned long value; #函数地址
    const char *name;    #函数名
};

# 导出符号的宏定义
#define EXPORT_SYMBOL(sym) __EXPORT_SYMBOL(sym, "")

#define __EXPORT_SYMBOL(sym, sec)                               \
        extern typeof(sym) sym;                                 \
        __CRC_SYMBOL(sym, sec)                                  \
        static const char __kstrtab_##sym[]                     \
        __attribute__((section("__ksymtab_strings"), aligned(1))) \
        = MODULE_SYMBOL_PREFIX #sym;                            \
        static const struct kernel_symbol __ksymtab_##sym       \
        __used                                                  \
        __attribute__((section("__ksymtab" sec), unused))       \
        = { (unsigned long)&sym, __kstrtab_##sym }

输出的符号表可以在/proc/kallsyms查看到。

6. 模块入口/退出函数

一般的c程序的入口函数是main，但模块的入口函数是module_init，退出函数则是module_exit。当内核启动或者执行insmod时执行module_init定义的函数，到内核关闭或者rmmod时执行module_exit定义的函数。

#define module_init(x)  __initcall(x);
#define module_exit(x)  __exitcall(x);

当然，还有一些宏定义了模块的一些信息，如
MODULE_AUTHOR
MODULE_DESCRIPTION
MODULE_ALIAS
MODULE_LICENSE
MODULE_PARM_DESC

7. 内存分配

内核中不能使用用户空间的malloc()和free()来分配/回收内存。而需要使用内核空间的内存分配/回收工作，常用的有kmalloc/kfree，基于slab内存分配算法：

void *kmalloc(size_t size, gfp_t flags)
void kfree(const void *objp)

对于slab内存分配器，这里不再详细展开。通过/proc/slabinfo或者slabtop可以查看slab内存分配的一些情况。

另外，在内核中也不能使用用户态的printf来输出信息，而需要使用内核态的printk。

8. 模块工具

8.1 insmod
Linux模块编译好以后一般是.ko文件，通过执行insmod可以将编译好的模块加载到内核中。在装载内核模块时，用户可以向模块传递一些参数：

$ sudo insmod mod_name var=key

8.2 rmmod
rmmod则用来卸载已经加载到内核的模块

$sudo rmmod mod_name

8.3 lsmod
lsmod可以列出已经加载到内核中的模块

lsmod
Module                  Size  Used by
nf_conntrack_ipv6       8785  1
aes_i586                7244  2
aes_generic            26755  1 aes_i586
ipt_MASQUERADE          1315  0
xt_state                 930  2
...

也可以通过/proc/modules来获取内核模块列表。

8.4 modinfo

查看某个模块的信息

$ modinfo raid0
filename:       /lib/modules/2.6.36-ningoo/kernel/drivers/md/raid0.ko
alias:          md-level-0
alias:          md-raid0
alias:          md-personality-2
description:    RAID0 (striping) personality for MD
license:        GPL
srcversion:     2CFE19548162CD6E80EE58B
depends:
vermagic:       2.6.36-ningoo SMP mod_unload modversions CORE2

8.5 modprobe

modprobe是一个比较强大的工具，既可以列出已经安装的模块信息，也可以用来加载/卸载模块，并且能够处理同时将依赖的模块自动进行加载。

$ modprobe -l

$ sudo modprobe -r mod_name
$ sudo modprobe mod_name

/etc/modprobe.conf和/etc/modprobe.d/保存了一些modprobe可能用到的配置。

未完待续

参考：
[1] 2.6内核模块编程实例指导
[2] 小白学Linux之内核模块编程

您可能也喜欢：
深入浅出Flashcache（四）	SSD硬盘时代即将到来？	Windows平台不支持32k的block size	SSD硬盘的IO性能测试	Redhat Enterprise Linux 5安装截图欣赏
无觅

假如一台主机插入了多块硬盘，单块硬盘的容量和性能都是有限的，如果能将多块硬盘组合一个逻辑的整体，对于这台主机来讲，就实现了最简单意义上的“云存储”。有很多方法可以实现这个目的，比如Raid卡硬件，比如现在很流行的分布式文件系统的replica机制，等等。Linux内核也看到了这个需求，于是2.6有了device mapper，当然device mapper不只是满足这一个需求，对于多路径IO也做了支持。

3. Device Mapper

简单来讲，Device Mapper是一种组合多个块设备变成一个逻辑块设备的机制。

Device Mapper的设计实现主要分为三层：

• Mapped Device： 映射出的逻辑设备
• Mapping Table： 映射规则表
• Taget Device： 底层的实际设备（可以是物理的块设备，也可以是Device Mapper映射出的逻辑设备），根据组合规则的不同，实际设备的使用方式不一样，区分为不同的类型。

(图片出处：参考[1])

Target device的类型，内核自带的几种包括（linux/include/linux/device-mapper.h）：

• linear: 线性，顺序使用target
• mirror: 镜像，类似于Raid 1
• stripped： 条带，类似Raid 0
• snapshot: 快照，LVM2的快照基于此实现
• multipath: 多路径IO
• crypt: 加密，可以实现加密存储
• delay: 延时IO
• …

Target type是一种模块化的插件接口，允许自定义。Flashcache就是利用这个接口定义了一种新的target type，将SSD和普通磁盘定义为两种新的target device，设计了缓存的映射规则，逻辑组合成一种新的块设备。

3.1 mapped_device

mapped_device定义了逻辑设备，对内核来说，可以把逻辑设备当作一种普通的block_device。

struct mapped_device {
    struct request_queue *queue;
    struct gendisk *disk;
    char name[16];
    void *interface_ptr;
    struct workqueue_struct *wq;
    struct dm_table *map;
    struct bio_set *bs;
    struct block_device *bdev;
    make_request_fn *saved_make_request_fn;
    ...
};

3.2 dm_table

dm_table描述了逻辑设备和物理设备之间的映射关系。

struct dm_table {
    struct mapped_device *md;
    atomic_t holders;
    unsigned type;
    unsigned int num_targets;
    struct dm_target *targets;
    struct list_head devices;
    fmode_t mode;
    ...
 };

3.3 dm_target

dm_target定义了一个具体的target device。

struct dm_target {
    struct dm_table *table;
    struct target_type *type;
    void *private;
    ...
 };

3.4 target_type

target_type定义一种target device的类型。其中有几个比较重要的函数:

• map: io映射规则函数
• ctr: 设备构造函数
• dtr: 设备析构函数
• end_io: IO操作完成后调用
• status： 获取设备状态信息
• ioctl：ioctl接口

struct target_type {
    uint64_t features;
    const char *name;
    struct module *module;
    unsigned version[3];
    dm_ctr_fn ctr;
    dm_dtr_fn dtr;
    dm_map_fn map;
    dm_map_request_fn map_rq;
    dm_endio_fn end_io;
    dm_request_endio_fn rq_end_io;
    dm_flush_fn flush;
    dm_presuspend_fn presuspend;
    dm_postsuspend_fn postsuspend;
    dm_preresume_fn preresume;
    dm_resume_fn resume;
    dm_status_fn status;
    dm_message_fn message;
    dm_ioctl_fn ioctl;
    dm_merge_fn merge;
    dm_busy_fn busy;
    dm_iterate_devices_fn iterate_devices;
    dm_io_hints_fn io_hints;
    /* For internal device-mapper use. */
    struct list_head list;
};

3.5 dm_register_target

dm_register_target函数用于注册 一个新的target type。

int dm_register_target(struct target_type *tt)
{
    ...
    list_add(&tt->list, &_targets);
    ...
}

3.6 dm_io

dm-io为device mapper提供同步或者异步的io服务。

使用dm-io必须设置dm_io_region结构（2.6.26版本以前叫io_region），该结构定义了io操作的区域，读一般针对一个dm_io_region区，而写可以针对一组dm_io_region区。

struct dm_io_region {
    struct block_device *bdev;
    sector_t sector;
    sector_t count;         /* If this is zero the region is ignored. */
};

dm-io一共有四种dm_io_mem_type类型（老一点的内核版本只有前面三种，Flashcache主要使用DM_IO_BVEC）:

enum dm_io_mem_type {
    DM_IO_PAGE_LIST,/* Page list */
    DM_IO_BVEC,     /* Bio vector */
    DM_IO_VMA,      /* Virtual memory area */
    DM_IO_KMEM,     /* Kernel memory */
};

struct dm_io_memory {
    enum dm_io_mem_type type;
    union {
            struct page_list *pl;
            struct bio_vec *bvec;
            void *vma;
            void *addr;
    } ptr;

    unsigned offset;
};

dm-io通过dm_io_request结构来封装请求的类型，如果设置了dm_io_notify.fn则是异步IO，否则是同步IO。

struct dm_io_request {
    int bi_rw;                      /* READ|WRITE - not READA */
    struct dm_io_memory mem;        /* Memory to use for io */
    struct dm_io_notify notify;     /* Synchronous if notify.fn is NULL */
    struct dm_io_client *client;    /* Client memory handler */
};

使用dm_io服务前前需要通过dm_io_client_create函数（在2.6.22版本前是dm_io_get）先创建dm_io_client结构，为dm-io的执行过程中分配内存池。使用dm-io服务完毕后，则需要调用dm_io_client_destroy函数（在2.6.22版本前是dm_io_put）释放内存池。

struct dm_io_client {
    mempool_t *pool;
    struct bio_set *bios;
};

dm-io函数执行具体的io请求。

int dm_io(struct dm_io_request *io_req, unsigned num_regions,
      struct dm_io_region *where, unsigned long *sync_error_bits)
{
    int r;
    struct dpages dp;

    r = dp_init(io_req, &dp);
    if (r)
            return r;

    if (!io_req->notify.fn)
            return sync_io(io_req->client, num_regions, where,
                           io_req->bi_rw, &dp, sync_error_bits);

    return async_io(io_req->client, num_regions, where, io_req->bi_rw,
                    &dp, io_req->notify.fn, io_req->notify.context);
}

3.7 kcopyd

kcopyd提供了一种异步copy服务，可以将一个block device上的一组连续扇区复制到一个或者多个block device中，很明显，这在mirror/snapshot等target type中是非常需要的功能。实际上flashcache也利用了该功能来实现cache的机制。

使用kcopyd前需要先通过dm_kcopyd_client_create函数（2.6.26版本前叫做kcopyd_client_create）创建一个dm_kcopyd_client

struct dm_kcopyd_client {
    spinlock_t lock;
    struct page_list *pages;
    unsigned int nr_pages;
    unsigned int nr_free_pages;

    struct dm_io_client *io_client;
    wait_queue_head_t destroyq;
    atomic_t nr_jobs;
    mempool_t *job_pool;

    struct workqueue_struct *kcopyd_wq;
    struct work_struct kcopyd_work;

    spinlock_t job_lock;
    struct list_head complete_jobs;
    struct list_head io_jobs;
    struct list_head pages_jobs;
};

dm_kcopyd_client维护了三job队列，一个等待内存页pages_jobs，一个已经获得内存页等待io命令io_jobs，一个等待io完成complete_jobs，这三个job队列都由job_lock锁保护。job队列由kcopyd_job结构组成。

struct kcopyd_job {
    struct dm_kcopyd_client *kc;
    struct list_head list;
    unsigned long flags;
    int read_err;
    unsigned long write_err;
    int rw;  # READ or WRITE
    struct dm_io_region source;
    unsigned int num_dests;
    struct dm_io_region dests[DM_KCOPYD_MAX_REGIONS];
    sector_t offset;
    unsigned int nr_pages;
    struct page_list *pages;
    dm_kcopyd_notify_fn fn;
    void *context;
    struct mutex lock;
    atomic_t sub_jobs;
    sector_t progress;
 };

dm_kcopyd_copy函数执行实际的copy动作，kcopyd一种异步任务，所以需要预先定义回调函数dm_kcopyd_notify_fn。

int dm_kcopyd_copy(struct dm_kcopyd_client *kc, struct dm_io_region *from,
                unsigned int num_dests, struct dm_io_region *dests,
               unsigned int flags, dm_kcopyd_notify_fn fn, void *context)
{
    struct kcopyd_job *job;
    job = mempool_alloc(kc->job_pool, GFP_NOIO);
    job->kc = kc;
    job->flags = flags;
    job->read_err = 0;
    job->write_err = 0;
    job->rw = READ;
    job->source = *from;
    job->num_dests = num_dests;
    memcpy(&job->dests, dests, sizeof(*dests) * num_dests);
    job->offset = 0;
    job->nr_pages = 0;
    job->pages = NULL;
    job->fn = fn;
    job->context = context;

    if (job->source.count < SUB_JOB_SIZE)
            dispatch_job(job);
    else {
            mutex_init(&job->lock);
            job->progress = 0;
            split_job(job);
    }
    return 0;
}

4. Device Mapper工具

操作系统提供了一些管理device mapper的工具，需要确认相关的包已经安装。

$rpm -qa | grep device-mapper
device-mapper-libs-1.02.62-3.el6.x86_64
device-mapper-1.02.62-3.el6.x86_64
device-mapper-event-libs-1.02.62-3.el6.x86_64
device-mapper-event-1.02.62-3.el6.x86_64

4.1 dmsetup

Device Mapper的工具主要是dmsetup，可以用来创建/修改/删除/查看DM设备，Flashcache的创建和装载工具flashcache_create/flashcache_load都是调用的dmsetup，只是自己包装了一层。

创建一个新的dm设备的语法为：

dmsetup create dm_device start_sector nr_sectors target argument

不同的target type，带的argument不一样，ctl函数定义了如何根据参数来构建dm设备的逻辑。如果组合的参数规则复杂，也可以将参数写入到文件中，然后通过文件参数来执行创建。

dmsetup create dm_device file_name

以下是一个已经创建好的Flashcache设备的信息：

$sudo dmsetup info
Name:              cachedev
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        1
Event number:      0
Major, minor:      253, 0
Number of targets: 1

$sudo dmsetup status
cachedev: 0 3093559296 flashcache stats:
	reads(731952), writes(554131825)
	read hits(663370), read hit percent(90)
	write hits(429687559) write hit percent(77)
	dirty write hits(185872576) dirty write hit percent(33)
	replacement(31918), write replacement(13045343)
	write invalidates(0), read invalidates(1)
	pending enqueues(13604453), pending inval(13604453)
	metadata dirties(347477454), metadata cleans(347477257)
	metadata batch(665458755) metadata ssd writes(29495864)
	cleanings(347468476) fallow cleanings(536679)
	no room(7246713) front merge(286174542) back merge(57729678)
	disk reads(68585), disk writes(368002849) ssd reads(347815066) ssd writes(562902592)
	uncached reads(1098), uncached writes(20849965), uncached IO requeue(0)
	uncached sequential reads(0), uncached sequential writes(0)
	pid_adds(2), pid_dels(2), pid_drops(0) pid_expiry(0)

$sudo dmsetup table
cachedev: 0 3093559296 flashcache conf:
	ssd dev (/dev/fioa), disk dev (/dev/sdb1) cache mode(WRITE_BACK)
	capacity(306408M), associativity(512), data block size(4K) metadata block size(4096b)
	skip sequential thresh(0K)
	total blocks(78440448), cached blocks(77048243), cache percent(98)
	dirty blocks(102), dirty percent(0)
	nr_queued(0)
Size Hist: 1024:2 4096:555006431 

未完待续

参考：
[1].Understanding Device-mapper in Linux 2.6 Kernel [Oracle Support ID 456239.1]
[2].Linux 内核中的 Device Mapper 机制
[3].Device-mapper Resource Page
[4].Linux Kernel Documents dm-io.txt
[5].Linux Kernel Documents kcopyd.txt

您可能也喜欢：
深入浅出Flashcache（四）	SSD硬盘时代即将到来？	Windows平台不支持32k的block size	SSD硬盘的IO性能测试	Redhat Enterprise Linux 5安装截图欣赏
无觅

在计算机系统中，cache的魔爪无处不在。CPU中有L1,L2,甚至L3 cache;Linux有pagecache，MySQL有buffer cache/query cache;IO系统中Raid卡/磁盘也有cache;在大型互联网系统中，数据库前面一般也都有一层memcache。Cache是容量与性能之前取平衡的结果，以更低的成本，获得更高的收益，是系统设计时应该遵循的原则。

传统机械硬盘几十年来，容量不断翻倍的增长，相比较而言，性能的增长就慢的像蜗牛了。对于依赖IO性能的应用，典型的如数据库，一直在等待新的技术来拯救。在此之前，身躯庞大的高端存储，动辄重达几吨。相比于存储里带的硬盘来说，价格贵得离谱，而存储的附加价值，在于io在大量硬盘之间的均衡分布，以及IO链路的多路容灾，以及部分固件层面的优化和数据保护等。

Flash disk(SSD/FusionIO等)的出现，改变了这一切。Flash disk将硬盘从机械产品变成了电气产品，功耗更小，性能更好，时延更优，看起来传统硬盘已经不堪一击，数据库欢欣鼓舞，新的革命似乎将一夕成功。但新东西也有它致命的缺陷，价格和经过时间检验的稳定性。

所以Facebook的Mohan Srinivasan在2010年开源了Flashcache，将Flash disk做为普通硬盘的cache，这个思路，目前一些尝试也在raid卡硬件层面做尝试，例如LSI的CacheCade Pro，不过之前版本新浪的童鞋测试过似乎性能没有想象的好。Flashcache在淘宝一些核心数据库中已经在线运行了大半年，经过调优后的表现稳定。Flashcache利用了Linux的device mapping机制，将Flash disk和普通硬盘的块设备做了一层映射，在OS中变现为一块普通的磁盘，使用简单，是一个值得推荐的方案。Flashcache最初的实现是write backup机制cache，后来又加入了write through和write around机制：

• write backup: 先写入到cahce，然后cache中的脏块会由后台定期刷到持久存储。
• write through: 同步写入到cache和持久存储。
• write around: 只写入到持久存储。

在详细的介绍Flashcache之前，需要先了解一下Linux的block device和device mapper相关的知识。

1. Block Device
块设备最初主要是依据传统硬盘等IO操作较慢的设备而设计的，所以Linux中为块设备的IO操作提供了cache层，所以基于块设备的请求一般是buffer io，当然后来由于数据库等自己有cache机制的应用，os/fs层面的cache就成了多余，所以出现了绕过os/fs层cache的direct io。

块设备在设备确定层和kernel之间，为Kernel提供了统一的IO操作接口，同时隐藏了不同硬件设备的细节。当有多个并发IO请求到块设备时，请求的顺序会影响IO的性能，因为普通的机械硬盘需要移动机械臂，所以kernel一般会对IO做排序等调度后再发送到块设备层。IO调度算法是一种电梯算法(elevator algorithm)，目前主要有cfq/deadline/anticipatory/noop，其中cfq是Linux的默认策略;anticipatory在新的内核中已经放弃;deadline在大部分OLTP数据库应用中更具优势，IO的响应时间更稳定些;noop只对IO请求进行简单的合并，其他不干涉，在FusionIO等IO性能很好的设备上，noop反而更具优势，所以FusionIO的驱动默认使用了noop。关于IO Scheduler，后文会有更详细的解释。

块设备在用户空间是一种特殊的文件类型，由(major,minor)来标识，major区分disk，minor区分partition。Linux中一般把设备文件放在/dev目录。实际上你完全可以将块设备文件创建到其他地方，只要(major,minor)唯一确定，块设备文件最后访问的起始同一个块设备。

$ls -l /dev/sda1
brw-rw—- 1 root disk 8, 1 2011-12-03 01:00 /dev/sda1

$sudo mknod /opt/sda1 b 8 1

$ls -l /opt/sda1
brw-r–r– 1 root root 8, 1 2011-12-03 11:54 /opt/sda1

由于块设备处于文件系统和物理设备驱动之间，在这一层做一些工作可以对所有IO产生影响，因此很多优秀的产品都在这一层做文章，除了Flashcache，还有一个比较著名的就是DRBD（DRBD已经进入2.6.33内核）。

在Linux内核中定义了一些操作块设备相关的结构体和函数，下面的信息基于2.6.32.49:

1.1 gendisk

gendisk保存了一个具体的disk的信息，包括该disk上的请求队列，分区列表/第一个分区，块设备操作表等重要信息。

struct gendisk {
    struct request_queue *queue;
    struct disk_part_tbl *part_tbl;
    struct hd_struct part0;
    const struct block_device_operations *fops;
    ...
};

1.2 hd_struct

hd_struct保存一个分区信息，包括起始扇区，扇区数，分区号等基本信息。

struct hd_struct {
    sector_t start_sect;
    sector_t nr_sects;
    int      partno;
    ...
};

1.3 disk_part_tbl

disk_part_tbl保存磁盘分区表的信息

struct disk_part_tbl {
    struct rcu_head rcu_head;
    int len;
    struct hd_struct *last_lookup;
    struct hd_struct *part[];
};

1.4 block_device

block_device可以是整个磁盘，也可以是一个分区。如果是一个分区块设备，则bd_contains会指向分区所在磁盘的block_device，bd_part则指向分区信息结构hd_struct。。

struct block_device {
    dev_t                    bd_bdev;
    struct inode            *bd_inode;
    struct list_head         bd_inodes;
    struct super_block      *bd_super;
    struct block_device     *bd_contains;
    struct gendisk          *bd_disk;
    struct hd_struct        *bd_part;
    struct list_head         bd_list;
    struct backing_dev_info *bd_inode_backing_dev_info;
    ...
};

1.5 buffer_head

顾名思义，在内核层对块设备的IO请求是以块为单位的。buffer_head是一个块在内存中的元数据信息。b_data指向该块数据的实际地址。b_this_page则将通过一page中的块连接起来。以前版本的buffer_head是fs到block device的io请求单元，现在已经改为bio了。

struct buffer_head {
    unsigned long        b_state;
    struct buffer_head   *b_this_page;
    char                 *b_data;
    sector_t              blocknr;
    struct block_device  *b_bdev;
    bh_end_io_t          *b_end_io;
    ...
};

1.6 bio

bio封装了一次实际的块设备io请求。这是块设备io请求的基本单位。bi_vcnt表示bio_vec的数目。

struct bio {
    sector_t             bi_sector;
    struct bio          *bi_next;
    struct block_device *bi_bdev;
    unsigned short       bi_vcnt;
    unsigned short       bi_idx;
    struct bio_vec      *bi_io_vec;
    ...
};

1.7 bio_vec

bio_vec表示一次bio涉及到的数据片段(segment)，由所在内存页地址，长度，偏移地址等定位。一次bio一般包含多个segment。

struct bio_vec {
    struct page            *bv_page;
    unsigned int            bv_len;
    unsigned int            bv_offset;
};

1.8 request

块设备层IO等待请求(pending I/O request)。内核中的bio请求在经过io调度排序后进入块设备层，会尝试合并到已有的requst。bio结构中的bi_next将队列中的bio请求串成一个队列。bio/biotail域指向队列的首尾。

struct request {
    struct list_head            queuelist;
    struct bio                 *bio;
    struct bio                 *biotail;
    void                       *elevator_private;
    void                       *elevator_private2;
    struct gendisk             *rq_disk;
    request_queue_t            *q;
    ...
};

1.8 request_queue

request_queue维护块设备层IO请求队列，队列中包含多个request。request_queue同时定义了处理队列的函数接口，不同的设备注册时需要实现这些IO处理接口。

struct request_queue {
    struct list_head            queue_head;
    struct request             *lastmerge;
    elevator_t                 *elevator;
    struct request_list         rq;
    request_fn_proc            *request_fn;
    make_request_fn            *make_request_fn;
    prep_rq_fn                 *prep_rq_fn;
    unplug_fn                  *unplug_fn;
    merge_bvec_fn           *merge_bvec_fn;
    prepare_flush_fn        *prepare_flush_fn;
    softirq_done_fn         *softirq_done_fn;
    rq_timed_out_fn         *rq_timed_out_fn;
    dma_drain_needed_fn     *dma_drain_needed;
    lld_busy_fn             *lld_busy_fn;
    struct blk_trace           *blk_trace;
    ...
};

1.9 submit_bh

submit_bh是内核发送IO请求给块设备的函数，目前较新版本的内核中该函数会调用submit_bio执行实际请求。

int submit_bh(int rw, struct buffer_head * bh)
{
    struct bio *bio;
    int ret = 0;
    ...
    bio = bio_alloc(GFP_NOIO, 1);

    bio->bi_sector = bh->b_blocknr * (bh->b_size >> 9);
    bio->bi_bdev = bh->b_bdev;
    bio->bi_io_vec[0].bv_page = bh->b_page;
    bio->bi_io_vec[0].bv_len = bh->b_size;
    bio->bi_io_vec[0].bv_offset = bh_offset(bh);

    bio->bi_vcnt = 1;
    bio->bi_idx = 0;
    bio->bi_size = bh->b_size;

    bio->bi_end_io = end_bio_bh_io_sync;
    bio->bi_private = bh;
    bio_get(bio);
    submit_bio(rw, bio);
    if (bio_flagged(bio, BIO_EOPNOTSUPP))
        ret = -EOPNOTSUPP;

    bio_put(bio);
    return ret;
}

1.10 submit_bio

submit_bio函数会调用generic_make_request执行实际的bio请求。generic_make_request则循环处理bio链表，针对每个bio调用内联函数__generic_make_request来做处理。__generic_make_request则最终调用request_queue中的make_request_fn处理函数处理实际的IO请求。

void submit_bio(int rw, struct bio *bio)
{
    ...
    generic_make_request(bio);
}

...
static inline void __generic_make_request(struct bio *bio)
{
    struct request_queue *q;
    int ret;
    ...
    do{
      q = bdev_get_queue(bio->bi_bdev);
      ...
      ret = q->make_request_fn(q, bio);
    }while(ret);
    ...

}

2. Block device相关的工具

Linux提供了一些工具来操作和查看块设备，如果你的系统中没有，可以安装最新版本的util-linux-ng来获得，实际上很多常用的工具都是出自整个工具集，本文后续也会用到其中一些有意思的工具。

2.1 lsblk

RHEL6.1中已经带有该工具。下面是一台已经配置好Flashcache的机器上执行的结果：

$lsblk
NAME                MAJ:MIN RM   SIZE RO MOUNTPOINT
sda                     8:0    0   200G  0
├─sda1                8:1    0   128M  0 /boot
├─sda2                8:2    0  14.7G  0 /
├─sda8                8:8    0     2G  0 [SWAP]
sdb                     8:16   0   1.5T  0
└─sdb1                8:17   0   1.5T  0
  └─cachedev (dm-0) 253:0    0   1.5T  0 /opt
fioa                  252:0    0 300.4G  0
└─cachedev (dm-0)   253:0    0   1.5T  0 /opt

2.2 blkid

blkid可以块设备的属性，不带参数也会列出系统中所有的块设备。

$ sudo blkid
/dev/sda1: UUID="0ff3ff63-d214-4d32-8633-66a4333fece9" TYPE="ext4"
/dev/sda6: UUID="d328b838-9043-438d-81b8-6a96454def3c" TYPE="swap"

2.3 blockdev

blockdev，不仅可以查看，也可以设置块设备的一些属性。

$ blockdev

用法:
  blockdev -V
  blockdev --report [devices]
  blockdev [-v|-q] commands devices

可用的命令:
	--getsz                        获得512字节的段大小
	--setro                        设置只读
	--setrw                        设置读写
	--getro                        获得只读
	--getss                        get logical block (sector) size
	--getpbsz                      get physical block (sector) size
	--getiomin                     get minimum I/O size
	--getioopt                     get optimal I/O size
	--getalignoff                  get alignment offset
	--getmaxsect                   get max sectors per request
	--getbsz                       获得块大小
	--setbsz BLOCKSIZE             设置块大小
	--getsize                      获得 32-bit 段数量
	--getsize64                    获得字节大小
	--setra READAHEAD              设置 readahead
	--getra                        获取 readahead
	--setfra FSREADAHEAD           设置文件系统 readahead
	--getfra                       获取文件系统 readahead
	--flushbufs                    刷新缓存
	--rereadpt                     重新读取分区表

2.4 fdisk

当然常用的fdisk也是管理块设备的利器。

$ sudo fdisk -l /dev/sda4

Disk /dev/sda4: 136.5 GB, 136492089344 bytes
255 heads, 63 sectors/track, 16594 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

2.5 blktrace

blktrace是跟踪块设备IO请求情况的利器。

blktrace is a block layer IO tracing mechanism which provides detailed information about request queue operations up to user space.

核心系统部的褚霸童鞋详细的介绍了这个个工具，有兴趣的移步这里，这里，还有这里。

2.6 lscpu

顺带说一下，lscpu也是一个很有用的工具，下面是2路intel L5630的主机上打印出来的信息，L5630是intel的低功耗CPU，额定功率只有常用的x5620的一半左右。

$sudo lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                16
On-line CPU(s) list:   0-15
Thread(s) per core:    2
Core(s) per socket:    4
CPU socket(s):         2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 44
Stepping:              2
CPU MHz:               2127.973
BogoMIPS:              4255.85
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              12288K
NUMA node0 CPU(s):     0,2,4,6,8,10,12,14
NUMA node1 CPU(s):     1,3,5,7,9,11,13,15

未完待续

参考：
[1]. Linux Block Device Architecture
[2]. Block devices and volume management in Linux

您可能也喜欢：
深入浅出Flashcache（四）	SSD硬盘时代即将到来？	Windows平台不支持32k的block size	SSD硬盘的IO性能测试	Redhat Enterprise Linux 5安装截图欣赏
无觅

这个PPT只是个读书笔记，可能有些理解有误的地方，如果发现了，请一定要留下评论。

您可能也喜欢：
关于HBase的一些零碎事	东南亚之旅：越南与柬埔寨（二）	雪色杭州，百年一遇	在Redhat Entrerprise Linux 5上安装Oracle11g截图欣赏	Windows平台不支持32k的block size
无觅

目前稳定版本的HBase0.90.2只能基于Hadoop0.20.x系列版本，暂不支持最新的0.21.x。而且官方版本的Hadoop0.20.2（或者0.203.0）缺少一个重要的特性，HDFS不支持sync模式的持久，这样HBase就有较大的丢失数据的风险。要在生产环境使用HBase，有两个选择，一是使用Cloudera的CDH3版本，Cloudera就类似MySQL的Percona，对官方版本的Hadoop做了很多改进工作，而且经典的《Hadoop：The Definitive Guide》一书的作者Tom White就是Cloudera的一员，这也和《High performance MySQL》一书的作者主要来是Percona一样。另外一种选择，就是自行编译Hadoop branch-0.20-append源码分支，这里有详细的说明。

对于HBase这种类似BigTable的系统，其优化之一是消除了磁盘的随机写。付出的代价是将最新的数据保存在内存表中，对内存有较大的需求。如果内存表的数量较多，则每个内存表就会在较小的时候刷到磁盘，导致磁盘文件多而且小。范围读取数据的时候就会跨多个数据文件甚至多个节点。为提升读性能，系统都会设计有compaction操作。另外为了防止某些情况下数据文件过大（hbase.hregion.max.filesize，默认256M，太大的数据文件在compaction等操作是对内存的消耗更大），HBase也设计了split操作。Compaction和Split操作，对于在线应用的响应时间都容易造成波动，他们的策略需要根据应用的特性进行调整。建议在业务低峰期手工调整。

HBase的regionserver宕机超过一定时间后，HMaster会将其所管理的region重新分布到其他存活的regionserver，由于数据和日志都持久在HDFS中，因此该操作不会导致数据丢失。但是重新分配的region需要根据日志恢复原regionserver中的内存表，这会导致宕机的region在这段时间内无法对外提供服务。而一旦重分布，宕机的节点起来后就相当于一个新的regionserver加入集群，为了平衡，需要再次将某些region分布到该server。 因此这个超时建议根据情况进行调整，一般情况下，宕机重启后即可恢复，如果重启需要10分钟，region重分布加恢复的时间要超过5分钟，那么还不如等节点重启。Region Server的内存表memstore如何在节点间做到更高的可用，是HBase的一个较大的挑战。Oceanbase也是采用内存表保持最新的更新数据，和HBase不同的是，Oceanbase使用的是集中的UpdateServer，只需要全力做好UpdateServer的容灾切换即可对业务连续性做到最小影响。分布还是集中，哪些功能分布，哪些功能集中，各自取不同平衡，是目前大部分分布式数据库或者存储的一个主要区别。当然，像Cassandra这种全分布的，架构上看起来很完美，实际应用起来反而问题更多。

对于java应用，线上运维最大的挑战之一就是heap内存管理。GC的不同方式，以及使用内存表和cache对内存的消耗，可能导致局部阻塞应用或者stop the world全局阻塞或者OOM。因此HBase的很多参数设置都是针对这两种情况。HBase使用了较新的CMS GC（-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode）。

默认触发GC的时机是当年老代内存达到90%的时候，这个百分比由 -XX:CMSInitiatingOccupancyFraction=N 这个参数来设置。concurrent mode failed发生在这样一个场景：
当年老代内存达到90%的时候，CMS开始进行并发垃圾收集，于此同时，新生代还在迅速不断地晋升对象到年老代。当年老代CMS还未完成并发标记时，年老代满了，悲剧就发生了。CMS因为没内存可用不得不暂停mark，并触发一次全jvm的stop the world（挂起所有线程），然后采用单线程拷贝方式清理所有垃圾对象。这个过程会非常漫长。为了避免出现concurrent mode failed，我们应该让GC在未到90%时，就触发。

通过设置 -XX:CMSInitiatingOccupancyFraction=N

这个百分比， 可以简单的这么计算。如果你的 hfile.block.cache.size 和 hbase.regionserver.global.memstore.upperLimit 加起来有60%（默认），那么你可以设置 70-80，一般高10%左右差不多。

（以上CMS GC的说明引自HBase性能调优）

目前关于HBase的书不多，《Hadoop： The Definitive Guide》第二版有一章，另外最权威的要算官方的这本电子书了。

这篇是最近看HBase过程中的一些零碎的东西，记录于此备忘。

您可能也喜欢：
HBase运维碎碎念	继续给鲜果抓Bug	我爱北京天安门	生死狙击，阴谋与英雄	几个车模
无觅

追求简单，做到极致，共勉之。

您可能也喜欢：

卸载rpm包遭遇error: specifies multiple packages

AIX基础知识：系统资源控制器(System Resource Controller)

AIX虚拟内存管理机制

AIX 5L网卡管理与配置

Oracle10gR2 Logical Standby(七)日常管理与优化

无觅

Sinh Cafe的车很准时的在6:30出发，差不多两个多小时后达到巴域边境(Bavet)，这里也是一个小赌城。Sinh Cafe的大巴提供柬埔寨边境签证服务，所以之前我们在国内只签了越南没有签柬埔寨，边境签收了25美元一人。签证和过关的速度很快，基本上十几分钟就通关了，连行李包都没让我们安检。进入柬埔寨境内，沿着一号公路朝金边(Phnom Penh，音：普农奔)继续前进，建筑风格明显一变，当地人也不再戴斗笠，而是宽沿帽，路边的卫生状况也开始变差。甚至很长一段路都是质量一般的沥青路面，快到金边的时候才又变成稍微平整些的水泥路面。在乃良渡口，车需要等轮渡过湄公河，稍微耽搁了点时间，司机还给看渡口的警察送了几瓶矿泉水。一路走走停停，过了中午十二点才到金边的Sinh Cafe，需要在这里换13:45的车到暹粒。时间紧张加上地方不熟，午餐也就简单的在Sinh Cafe里解决了，金边的Sinh Cafe明显比胡志明的差了几个档次，食物以美元标价，东西一般但价钱不低，柬埔寨本地的货币瑞尔(Riel)只有在小于一美元找零的时候使用，一般按照一美元兑换四千瑞尔的比率计算，所以来柬埔寨只需要换美元就足够了。

在车上，坐我们旁边的是一对北京的夫妻，慢慢的聊熟了。晚上七点多抵达暹粒，我们同样没有预订酒店。一问，北京夫妇的功课做得足，不仅酒店早就有预订，还联系了一个当地的司机，把接下来两天的租车也都谈好了，司机还到Sinh Cafe来接。于是我们又跟着他们混，入住了Golden Temple Villa Guest house，房间比较小，不过旅馆门前的一片热带雨林风格的花园很有感觉，14刀一晚的价格也还算便宜，提供免费wifi，免费coffee，免费台球，免费按摩…，打了很多免费的招牌，不过免费的么，质量自然就不能强求。接下来两天到吴哥窟的车也和司机查理谈妥了，四个人租辆凯美瑞，司机全天陪同送往不同的景点，包括两次看日出日落，一共43美元。我们两个懒人，就这样顺利的解决了暹粒的行程安排，非常感谢北京夫妇的帮忙，旅途上总是好人多。

在较大的地图中查看Golden Temple Villa

住宿搞定，赶紧找地方吃饭。有做好功课的北京同学，这个问题比较容易解决了。直奔离酒店不远的Old Market附近的繁华酒吧街，找到据说是安吉丽娜朱莉推荐鸡尾酒的Red Piano，味道还行，价格稍显贵，不过还在可以接受的范围内。在Old Market附近的这条街都是饭店，而且很多都拉着横幅写着Lonely Planet推荐。暹粒其实也就是一个小镇，能吃的就那么几家，几乎都被Lonely Planet提过了。不过后来我们的司机给我们带到LuckyMall旁边的一家LyLy Restaurant，他家的猪肉做得不错，由于离热闹的Old Market较远，游客很少，很多本地人在吃，价钱就便宜很多，一份猪肉炒饭只需要2美元。在暹粒和吴哥窟，建议不要轻易点牛肉，我们吃过几次都嚼不太动，还是猪肉做得更好些。在吴哥窟逛的两天，中午都是司机带我们在景点附近就近解决的，价格比市区贵，而且快餐么，要求就不要太高。

吴哥窟经典玩法基本需要三天，所谓的小圈一天，大圈一天，外圈一天。我们和北京夫妇都是23号离开，所以只有21/22两天的时间，外圈就直接放弃了，太远而且景点分散。一天的门票是20刀，连续三天是40刀，还有七天内任意三天的，因为不符合我们的行程，就没有去关注了。第一天我们计划看日出日落，所以早上五点就起床赶往Angkor Wat前左边的莲花池，人倒是不少，不过今年雨季提前到来，运气不好，只看到太阳被乌云死死压住的阴沉沉的吴哥窟。而且一天逛下来，加上前一天十二个小时的长途汽车奔波，到下午两三点的时候就都扛不住打道回府了，巴肯山的日落就留给了第二天。不过22号傍晚虽然登上了巴肯山，日落也还是因为乌云遮盖没看成。好吧，这样也好，吴哥窟留给我们的，就都是雄奇精美不可思议的石头宫殿，日出日落的遗憾，恐怕也无法遮盖一千多年前的文明的光辉。

Lalla在暹粒买了一些纪念品，都是当地较有名的丝织品，如丝巾，花布床单一类。这里的市场比较混乱，漫天要价，就地还钱是普遍现象，勾起了我对小时候赶集的感觉。往往是照着三分之一的价格砍下去还是能够比较顺利的成交。暹粒有三个市场，Old Market周围比较热闹，游客多，价格更加坚挺些。Night Market我们没有进去过，不知道行情如何。稍微偏远些的Central Market是我们的主战场，丝巾我们砍到1.5美元，买了两床床单，一床8美元，一床10美元，值不值，就要问lalla同学了，不过鉴于该同学一向的购物欲和价格不敏感，应当肯定是满意的。在吴哥窟各个景点，更是小商贩云集，很多是几岁到十来岁的小孩。虽然柬埔寨的柬语小学是免费的，当地的父母还是更愿意让小孩出来赚美元，或乞讨或贩卖小商品。甚至很多小孩在看见我们都会用中文说，给我糖果。来吴哥窟的中国游客不知道有多少，居然能将当地的小孩训练出流利的普通话乞讨和叫卖。。。

拍了些吴哥窟的照片，还没来得及整理，先把这篇流水帐记下吧。

您可能也喜欢：
东南亚之旅：越南与柬埔寨（三）	东南亚之旅：越南与柬埔寨（二）	东南亚之旅：越南与柬埔寨（一）	MySQL5.1新特性（一）日志的增强	OOW2009美国行:金门大桥与奥巴马
无觅

去年在巴黎，十三区有一家pho14，是一家解放前移民的老华侨开的，其汤清淡悠远，米粉细韧有劲，吃过以后怀念至今。越南的pho一般不特指就是牛肉粉，并且生牛肉粉更加鲜美些。在胡志明，大街小巷的小吃店，基本都有pho，口味不一，好坏就要碰些运气了，我们第一天吃的就很差劲，汤无味，粉太烂，口感全无。有差的，当然也有好的，在笨蛋市场(Ben Thanh Market，滨城市场)旁边有一家pho2000，店子不大，门口上挂着粉红色的招牌，进去以后，在左手边的墙上，赫然有一张克林顿同学2001年在这里吃pho的照片（怪不得招牌下写着pho for the president），既然10年前美国总统都来这里，我们又幸在10年后走进同一家店子，这就是缘分么，呵呵。人很多，我们点了牛肉粉和鸡肉粉，上菜很快，这就是吃米粉的好处，米粉和汤都是早就准备好的，客人一到就可直接呈上。汤清淡而有余味，肉也很鲜嫩，相对还是牛肉更好，有劲道些，鸡肉则稍显淡。吃Pho都流行自己加豆芽和一些金不换或者薄荷的叶子，多少随意，东南亚的小辣椒都极辣，不能吃辣者要小心。国内的豆芽是已经不能吃了，越南目前应该还是安全的吧。价钱么，记不太清楚了，应该在50000盾左右。胡志明吃的物价，基本上应该在杭州一半的样子吧，街边的小吃就更便宜了：

地方很好找，就在Ben Thanh Market旁边，Le Lai和Phan Chu Trinh街交叉口：

在较大的地图中查看pho2000

另外，在很多旅行者的攻略上，都有推荐的pho24，是一家有较多分店的连锁，今天晚上，在离开胡志明前的最后一顿晚餐，回来的时候在范五老街上碰到一家，进去尝了一下，虽然不算坏，但感觉和pho2000还是有些差距，他们家的pho all，把牛肉，肉丸等多种添加料都加了进来，62000盾一碗：

至于春卷，则还是昨天晚上在笨蛋夜市一家叫做Hai Nam的排挡吃到的感觉最好，就在笨蛋市场相对pho2000的另外一条Phan Boi Chau街上，对面楼顶上有很显眼的Sanyo广告牌。这家Hai Nam的厨娘在排挡旁边的露天厨房现场操作，生意很红火。打开菜单才发现原来这里主要是吃海鲜的。我们点了雪蛤，扇贝，甘蔗虾，生春卷，后来又加了一盘炸春卷，共375000盾，约相当于120RMB，这是我们在胡志明吃的最贵的一餐了，一般都是20w左右就可以连吃带喝都解决了。和国内的做法不太一样。雪蛤是全熟的，搁了很多过了油的蒜粒，而扇贝则是用了葱和花生仁，香气四溢，甘蔗虾则是在一小节小甘蔗上面裹着厚厚的虾肉。

他家的炸春卷，鲜肉多而不腻，同样放了花生仁，虽然看起来炸得有些过头，裹以青菜叶，沾点鱼露，一咬之下满口余香，赞。生春卷也不错，不过他家调的虾酱我们都不太习惯：

今天上午在外面瞎逛的时候，lalla发现一家叫tung hung的馄饨(wonton)面馆，这是一家源自1968年的老店，店面很小不起眼，不注意很容易错过，就在我们住的地方不远，味道极好，尤其是里面的猪肉，有老家吃米慢慢长大的猪肉的香味。我们点了他最贵的馄饨米粉面和馄饨汤，62000盾一碗，饮料点了三色冰和清补凉，都值得推荐，调料花生仁和泡大蒜很有特点。这些老店能几十年坚持下去，自然不容易：

门口炖着的猪肉和丸子，看着就很诱人：

从我们住的小巷子往碧文街(Bui Vien St)走出来，然后右拐到De Tham走过一个街口就是：

在较大的地图中查看Tung Hung馄饨面

其实也不用到处走，我们住的这条小巷子里就有很多好吃好喝的。我们住的TiTi旅馆对面，有一家叫Beautiful Saigon II Hotel的，就有我们吃过最好的椰子炒饭和菠萝炒饭，一份55000盾。再过去一点有一家CAM Hotel，有我们喝过最好的Mango Shake和Mango Juice，分量足，不兑水，新鲜浓郁，只须40000/48000盾，不过这家吃的东西都不行，好几个晚上我们都是在这里点杯芒果汁就坐上几个小时。还有很多的街头小吃，能吃到什么就要随缘了，很多都是挑着担子当街叫卖的，碰上了别放过，不过卫生就不是太敢保证了，反正我们运气还不错，吃了不少也没有什么不良反应。沿着范五老街向笨蛋市场相反的方向走不到一公里，有一个本地的菜市场，这里也有很多便宜的街头小吃，胆大的话可以试试，我们在这里喝过8000盾的三色冰，便宜好喝，让我一下子想起了去年在普吉开车路过的一个当地市场，一位老奶奶调制的10Baht的三色冰，幸福不需要想太多，往往在太阳快晒晕的时候，一杯廉价清凉的三色冰，幸福便不期而至。

您可能也喜欢：
东南亚之旅：越南与柬埔寨（二）	东南亚之旅：越南与柬埔寨（一）	MySQL5.1新特性（一）日志的增强	关于Change Data Capture（一）	OOW2009美国行:大会第三天
无觅

这样我们在胡志明一共要待四天，想想不能都在市区里喝咖啡，还是得去看看传说中的湄公河（Mekong River）。在一家叫SahaBook的书店楼下，有一家叫InnoViet的旅行代理，我们在这里了解了一下湄公河一日游的情况，选择这家是因为被SahaBook上面的Lonely Planet Authorized Contributor的牌子吸引，其实这家InnoViet跟SahaBook和LP都没什么关系，不过接待的MM英语很流利，而且还有完整的PPT介绍，最终我们在这里定了湄公河一日游的大团，15美元一人。还有8人的private小团，要60刀，多一些如摘水果的项目。一天玩完回来后，我们还是很庆幸选了便宜的，因为即使是便宜的15刀，性价比也一般，两日游的话，第二天就是农家乐了。像这样的短途游，这里发展得还不是很规范，过多的购物推荐，重复的行程设置，以及泛黄的河水，都让人来了一次不愿意来第二次。或许看过杜拉斯的《情人》，会对湄公河有一种别样的感觉，可惜我只听过没看过。看着湄公河发黄的水，和河上一艘艘吃水很深的采沙船，我还是很有些为这条河的未来担忧的。

湄公河(Mekong River)，干流全长4880公里，是亚洲最重要的跨国水系，世界第六大河流；主源为扎曲，发源于中国青海省玉树藏族自治州杂多县。流经中国、老挝、缅甸、泰国、柬埔寨和越南，于越南胡志明市流入南海。流域除中国和缅甸外，均为湄公河委员会成员国。湄公河上游在中国境内，称为澜沧江，下游三角洲在越南境内，因由越南流出南海有9个出海口，故越南称之为九龙江，总长度2139公里

本来约好的18号早上7:25到InnoViet门口等车，结果手机虽然设了闹钟，但忘了改时区，于是很悲催的提前了一个小时被吵起来，出门的时候才想起，又回去补了个回笼觉。而当地人似乎对于守时也没有什么概念，在InnoViet门口等过了差不多十分钟才有人来接，然后在车上又等其他旅客，8点多了才发车，到达湄公河边的美萩市(My Tho)的码头时，已经10:30了。这码头上居然也有免费WIFI信号，不得不佩服越南的网络基础建设。码头上最热销的是越南特色的斗笠，和我老家用竹子编制的重而精致的斗笠不一样，这种用看起来是蒲草（我们老家用来做蒲扇的）编制的斗笠很轻巧，且没有固定用的头环，只是用一条绳布，带起来不费劲，且一下子就有了越南风情，一美元一顶。

查看大图

我们一团30人，先坐大船到一条小支流入口，再换成十人的小船，沿支流搠江而上，在热带丛林里穿梭，这是这一日游里最有价值的一段，可惜泥沙和黄河有一比的河道缺乏了一点味道。接下来的项目，和网上一些几年前的攻略没什么区别，手工椰子糖作坊，吃午餐，喝蜂蜜茶，听当地小曲，处处都有需要给钱的“增值项目”，手工椰子糖30000盾一包，买五送一，蜂王浆10美元一小瓶，听曲的小费就随你给了。最后走上一小段路，搭一程双人划的小木船，在丛林深处一溜儿的划向我们归途的大船。 上船之前，导游还特地交代给划船的船娘一些小费。本来我们15美元是包含了回程的大巴费用的，不过在导游的劝说下，我们又掏了10美元每人，改坐快艇走水路回胡志明，说是会更快一些，实际上也花了两个半小时才回到西贡河码头。途中还碰到了倾盆大雨，这应该还是我在东南亚碰到的第一场雨，巧的是，在穿出雨区后，还看到了半条彩虹。

回到市区后，我和lalla决定晚餐去笨蛋夜市昨天看到的很多厨娘在开放式厨房忙碌的那家Hai Nam，就在Sanyo广告牌的街对面。坐定后才发现这家是吃海鲜为主的，价格相对于之前两天吃的要贵不少，这一顿花了我们375000，目前为止最贵的一顿了，折合RMB差不多120左右，在杭州的话，也就一般饭店的消费吧。关于吃的，准备明天专门写一篇来介绍，这一篇就此打住，最后上几张照片：

湄公河上的捞沙船

搠江而上的热带丛林

宠物鸡，立船头

椰子压榨机

纯手工椰子糖

这个杀手不太冷

船工的期待

船娘的背影

上大船，回去咯

您可能也喜欢：
东南亚之旅：越南与柬埔寨（三）	东南亚之旅：越南与柬埔寨（一）	MySQL5.1新特性（一）日志的增强	奥运	Cognos DecisionStream简介(一)
无觅

15号从杭州到吉隆坡，这里是亚航的大本营，一般都需要在这里中转。抵达的时候已经是晚上七点多，因为一年前来过，所以轻车熟路的找到了过境签的immigration counter，运气好没有排队，不到五分钟就拿到了120个小时的马来西亚过境签。因为机场的tune酒店要300多RMB一晚，我们定了市区的青年旅社，27林吉特（马币，约合57.5RMB）一个床位，从亚航机场LCCT（Low Cost Carrier Terminal，廉价机场）到市区KL Sentral中央车站，有AeroBus和SkyBus等几家相互竞争的车，AeroBus便宜点，单程8林吉特，往返则只需要14，而Skybus需要10林吉特单程。LCCT机场一个小时左右可以到市区， KL Sentral可以很方便的搭轻轨到大部分地方，我们定的Sunshine Bedz青年旅社在Bukit Bintang站，本来可以搭车MonoRail（绿色的MR线）直达的，2.10马币即可。不过MR线的车站在KL Sentral车站旁边的一条街，我们没有找到，于是问KJ线的售票窗口，结果售票员让我们先乘KJ线到Da Wangi，然后换乘MR，站数一样。不过后来悲剧的发现，KJ和MR是两家公司运行的线路，不互通，需要出站，并且走5分钟左右才能到另外一条线的站台，而且，还少找了我们5林吉特。本来对吉隆坡的印象就不太好，这个城市注定只能成为中转站。

View Larger Map
注：放大地图，可以看到KL Sentral和MonoRail的站隔着一条路，需要搭乘MR线的朋友可以留意一下。

MR线是单轨城铁，车很小巧，只有两节车厢，站台的指示牌需要看仔细了，Platform1和Platform2的行驶方向要注意，我们16号早上赶飞机的时候就不小心就坐反了方向，不但没赶上预期的7:15的车，差点连7：45的都没赶上，要是再等半个小时后的下一版，到时候可能就无法登机了，好险，好在大巴票是一个月有效随便坐的。在机场的Taste of Asia吃了两碗面做早餐，LCCT还有家Old Town White Coffee，在马来西亚挺有名的，吃的东西也不错，不过白咖啡我喝着没什么感觉，去年买了一袋回去最后都没喝完。吉隆坡是东八区，而胡志明是东七区，关于这个时区，我纠结了很久，从地图上看，似乎吉隆坡更靠西，而胡志明更靠东一些，没搞明白吉隆坡怎么就成了东八区，胡志明却成了东七区。

当地时间10点左右到达胡志明，我们在国内只换了点美元，因此出机场后第一件事就是换越南盾，10美元可以换到209500，哥一下暴富了，什么百万富翁，真的全都是浮云。不过后来后悔了，在机场换得太少，市区的汇率还不如机场的呢。换汇的地方有到市区的taxi，明码标价7美元，外面有拉客的黑车，还有要10美元的，都不必管他。胡志明西贡机场有到市区的SaigonBus，当时上去得匆忙没注意看线路号，网上有攻略说152路，姑且就算它是吧，只需要4000越南盾（VND）即可，约合1.25RMB，很便宜，而且终点站就在我们要去的范五老街附近的Ben Thanh Market（滨城市场，我第一次听发音感觉像笨蛋市场，后来就被我称之为笨蛋市场了）。这次除了吉隆坡的青年旅社，全程我们都没有预定酒店，纯裸游。因此在公交车上看到前面的一家三口在看地图，lalla就搭讪问范五老街(Pham Ngu Lao)应该在哪一站下车，正好来自菲律宾的他们也是去这一片的背包客聚集区，我们就很厚脸皮的要求跟他们同行。其实他们也不是很认路，下车后一路地图一路问，总算找到了一片旅馆密集的街区，他们定的是30美元一晚的，有点小贵，因此我们在这里分手，他们家的小朋友非常可爱，后来发现胡志明的小孩子一个个都长的很好，细腻白嫩的，让人忍不住想捏一吧。我们跟着街边一位专门替各旅馆拉客的阿姨拐到了旁边一条小街，找到了一家20美元的，其实如果愿意多花点时间，15美元的也有。不过这家叫TiTi的小旅馆我们已经很满意了，接待我们的大妈英语虽然不是很好，但笑得很有爱，而且房间也很干净，还是一个三人房。这是一条小巷子，就在碧文街(Bui Vien)40号和范五老街之间，里面聚集了10几家小旅馆和餐厅，随便一家都有美味，当然有些是饮料好喝，有些是炒饭诱人，各种滋味，可以一家家慢慢品尝过去。不过TiTi对面的Beautiful Saigon II Hotel的椰子炒饭和菠萝炒饭真是一流，水果很新鲜，炒饭软硬适中，吃过就不会忘记。

View Larger Map

胡志明很多街道用的是人名，范五老是越南历史上的一位军事英雄：

范五老（Phạm Ngũ Lão，1255年－1320年）越南陈朝将领。历仕陈仁宗、陈英宗、陈明宗三朝。他的才能为兴道王陈国峻所赞赏，陈国峻将自己的义女嫁给了范五老，使他成为皇室的一员。作为将军，范五老的战绩突出；他尚未成为陈朝皇室成员时，曾在陈朝第二次和第三次抗元战争中发挥重要作用。在元越战争之后，范五老又先后参加过多次战役，这些战役大多数以胜利告终。如今越南人依旧把他视作越南历史上少有的杰出军事家之一。胡志明市也有一条街以他的名字命名。

这几天待在胡志明，我们也没有特别的目的，市内有什么经典景点也没怎么了解，一路都是兴之所致，走走停停，尝尝街边的美食，溜溜曲折的弄堂，逛逛本地的菜场，看看西贡河边的夕阳。在一家小店喝着大杯的浓郁Mango Shake的时候，碰到了一位上海的大叔，说是38岁后开始旅行的生活，因为有哮喘，医生建议到南方过冬，然后在海南待了五年，一个偶然的机会，从结识的一位驴友那里知道了亚航，然后在驴友的帮助下有了第一次的东南亚之行，之后一发不可收拾，把上海的房子出租，然后一年多的时候有九个多月待在东南亚，从一个国家到一个国家，一个城市到一个城市，悠闲的一边生活一边旅行，往往一个地方一待就是一两个月。他这次是从柬埔寨入境越南，签证有半年，而我们从国内签出来才一个月。不过从这位大叔吹嘘的地方来看，他还不能算专业的背包客，爱吃中国菜，去的地方往往也季节不好，不过这样闲散而舒适的生活，确实让我们羡慕嫉妒恨啊。

在胡志明已经待了两天，最大的一个印象，就是摩托车多，不管大街小巷，摩托车行云流水的一样的飞驰，偶尔还有飙车族大声轰鸣，而路上有红绿灯的地方不多，要过马路都得打起十二分的精神，左顾右盼，然后瞅准时机，否则又得耐心的等上一段时间了。满街的摩托车，大部分是Honda，据说以前中国产的很多，后来逐渐被日本产取代了。在笨蛋市场沿范五老街有一大片开放的绿地公园，到了晚上，一对对的青年男女坐在摩托车上促进友谊，我甚至怀疑，在胡志明，要是你没有一辆拉风的摩托车，你都不好意思出来谈恋爱。越南MM一个个身材超好，腰细而臀翘，如果穿上传统的袄黛，一阵风过，裙摆扬起，露出腰部的细腻肌肤，万钟风情，千分妩媚，不过回眸一笑间。对胡志明的另外一个印象，就是wifi随处可见，而且没有GFW。任何一家旅馆，餐厅，咖啡厅，都有自己的wifi，停下来一搜信号，都是10几个，有些还是没有设置密码的，在烈日下走累了，随便找家咖啡点一坐，喝一杯当地的冰辛辣茶拿铁，拿出手机或者电脑上会儿网，看着窗外的绿树成荫，这是多少小资理想中的生活。所以我给胡志明的定义是，小资与摩托车的天堂。

在一家LonelyPlanet认证过的书店楼下一家叫做InnoViet的旅游代理处，我们预定了18号的湄公河（Mekong River）一日游，一开始我们还以为是LP认证过的旅游代理呢，搞了个乌龙。不过代理处的小姑娘英语很流利，还会法语，给我们的介绍很专业，还有PPT演示。一日游分30人的大团和8人的小团，小团有更多的项目，如自行车或者牛车之旅，制作手工椰子糖等，需要60美元/人，而大团则只需要15美元。如果选择两日游，更是可以参与当地的农家乐，在当地人家里住上一晚上。我们时间有限，也不想太累，就定了大团。明天还得早起，赶7：30的车，该睡觉了。

虽然带了相机，但现在没有拍照的兴趣，那是为吴哥窟准备的器材。这两天只是手机随手拍了几张，这个流水帐就不弄照片了。有兴趣的，可以跟随我的新浪微博，在接下来的10来天里，和我一起享受胡志明吴哥窟金边之旅（原计划只有胡志明吴哥窟的，因为在金边的九毛同学的盛情邀请，今天临时决定改道金边多待几天）。

您可能也喜欢：
东南亚之旅：越南与柬埔寨（三）	东南亚之旅：越南与柬埔寨（二）	MySQL5.1新特性（一）日志的增强	Apache Derby Database介绍	OOW2009美国行:纽约一日游
无觅

• mongod：数据库服务端，类似mysqld，每个实例启动一个进程，可以fork为Daemon运行
• mongo：客户端命令行工具，类似sqlplus/mysql，其实也是一个js解释器，支持js语法
• mongodump/mongorestore：将数据导入为bson格式的文件/将bson文件恢复为数据库，类似xtracbackup
• mongoexport/mongoimport：将collection导出为json/csv格式数据/将数据导入数据库，类似mysqldump/mysqlimport
• bsondump：将bson格式的文件转储为json格式的数据
• mongos：分片路由，如果使用了sharding功能，则应用程序连接的是mongos而不是mongod
• mongofiles：GridFS管理工具
• mongostat：实时监控工具

最简单的，通过执行mongod即可以启动MongoDB数据库服务，mongod支持很多的参数，但都有默认值，其中最重要的是需要指定数据文件路径，或者确保默认的/data/db存在并且有访问权限，否则启动后会自动关闭服务。Ok，那也就是说，只要确保dbpath就可以启动MongoDB服务了：

$ ./mongod --dbpath /tmp
Fri Apr  1 00:34:46 [initandlisten] MongoDB starting : pid=31978 port=27017 dbpath=/tmp 32-bit 

** NOTE: when using MongoDB 32 bit, you are limited to about 2 gigabytes of data
**       see http://blog.mongodb.org/post/137788967/32-bit-limitations
**       with --dur, the limit is lower

Fri Apr  1 00:34:46 [initandlisten] db version v1.8.0, pdfile version 4.5
Fri Apr  1 00:34:46 [initandlisten] git version: 9c28b1d608df0ed6ebe791f63682370082da41c0
Fri Apr  1 00:34:46 [initandlisten] build sys info: Linux ning 2.6.36-ningoo #1 SMP
Wed Nov 17 21:45:13 CST 2010 i686 BOOST_LIB_VERSION=1_42
Fri Apr  1 00:34:46 [initandlisten] waiting for connections on port 27017
Fri Apr  1 00:34:46 [websvr] web admin interface listening on port 28017

mongod的主要参数有：

dbpath: 数据文件存放路径，每个数据库会在其中创建一个子目录。用于防止同一个实例多次运行的mongod.lock也保存在此目录中。
logpath：错误日志文件
logappend： 错误日志采用追加模式（默认是覆写模式）
bind_ip： 对外服务的绑定ip，一般设置为空，及绑定在本机所有可用ip上，如有需要可以单独指定
port： 对外服务端口。Web管理端口在这个port的基础上+1000
fork： 以后台Daemon形式运行服务
journal：开启日志功能，通过保存操作日志来降低单机故障的恢复时间，在1.8版本后正式加入，取代在1.7.5版本中的dur参数。
syncdelay： 执行sync的间隔，单位为秒。
directoryperdb： 每个db存放在单独的目录中，建议设置该参数。
maxConns： 最大连接数
repairpath： 执行repair时的临时目录。在如果没有开启journal，异常宕机后重启，必须执行repair操作。

在源代码中，mongod的参数分为一般参数，windows参数，replication参数，replica set参数，以及隐含参数。上面列举的都是一般参数。如果要配置replication，replica set等，还需要设置对应的参数，这里先不展开，后续会有专门的文章来讲述。执行mongo –help可以看到对大多数参数的解释。但有一些隐含参数，则只能通过看代码来获得(见db.cpp po::options_description hidden_options(“Hidden options”);)，隐含参数一般要么是还在开发中，要么是准备废弃，因此在生产环境中不建议使用。

可能你已经注意到，mongod的参数中，没有设置内存大小相关的参数，是的，mongodb使用os mmap机制来缓存数据文件数据，自身目前不提供缓存机制。这样好处是代码简单，mmap在数据量不超过内存时效率很高。但是数据量超过系统可用内存后，则写入的性能可能不太稳定，容易出现大起大落，不过在最新的1.8版本中，这个情况相对以前的版本已经有了一定程度的改善，具体请参考realzyy的测试。

这么多参数，全面写在命令行中则容易杂乱而不好管理。因此，mongod也和mysqld一样支持将参数写入到一个配置文本文件中，然后通过config参数来引用此配置文件：

./mongod --config /etc/mongo.cnf

至此，已经成功的运行了一个单机的mongodb实例。

您可能也喜欢：
白话MongoDB（二）	NoSQL，关系数据库终结者？	Oracle11g将于7月11号在New York正式发布	Gearman for MySQL	Oracle11g新特性：Flashback Data Archive
无觅

南浔自清同治光绪以来，涌现了一批因经营“辑里湖丝”而发家的巨富，号称“四象八牛七十二金狗”，四象之首的刘镛（这个可不是那个传说中的刘罗锅，那是刘墉，山东人，一开始我也被这个名字搞晕了），据说家财两千万辆百银，而当时清政府一年的财政收入也不过七千万辆，这是真正的富可敌国啊，南浔最大的景点之一，小莲庄就是他的私人庄园。有了钱，中国人都喜置地盖楼，在南浔就留下了大量私家庄园和旧宅。现今南浔主营木地板，依然是富庶的江南古镇，有“中国木地板之都”之美誉，当地人说这里旅游只是副业，从这两三天来看，确实如此，无游人商贾摩肩接踵，无车马丝竹乱耳扰神，不像乌镇西塘等其他古镇，这里居然是难得清幽。唯一不足处，这河里的水实在是有伤风雅，尤其是景点密集处，不忍入目。

去年今日此门中，人面桃花相映红。人面不知何处去，桃花依旧笑春风。（崔护《题都城南庄》）

由于是清明假期，南浔的住宿还是偏紧张，lalla在中国古镇网上预订的时候，本想预订的“云水谣”已经满座，“茶之韵书吧”也只有第二天晚上才有房间，第一天只能在“浔北旅馆”将就下了，虽然浔北的老板人很好，不过住宿条件确实一般，160的价钱也谈不上太好的性价比，据说平时只需要80。而第二天晚上住的“茶之韵书吧”，200的价格就比较超值了。位置在百间楼西，二楼开窗，正对河道，楼下有书，可随意取阅。不像小莲庄附近的古镇多是复原之作，百间楼由于离主景区有一定距离，更显真实的古朴。百间楼从明代万历年间开始陆续而建，有明清两代的江南建筑风格，值得细细品尝。

百间楼上倚婵娟，百间楼下水清涟；每到斜阳村色晚，板桥东泊卖花船。（张镇《浔溪渔唱》）

慵懒河边排排坐，幸福时光指尖流

第二天中午在古镇口的香聚楼吃完，以100的价格租了条小木船，这里摇船的都是船娘，可从水路入景区。景区需要收100的门票，包括小莲庄，嘉业堂藏书楼，张静江故居，张石铭故居等，景区古镇街口也陆续有几个检票口，但检查不是很严格，运气好如我们，则没有碰到查票的，下午四点半下班后后则可以随意进出景区街道。

船行两岸春不住，桥上行人花正浓

这里的小吃，主打是麦芽糖，芡实糕和臭豆腐，几个江南古镇都差不多。在去小莲庄的河口，碰到一家做淘宝店的芡实糕店家，在淘宝上经营两年，已经是四钻卖家，小伙子热情的邀我们品尝，有兴趣的朋友可以去光顾下这家“祥和糕点坊”，其精品芡实糕确实是不错，不过店铺设计得有点丑，哈哈。说到吃，南浔还是有几个口碑不错的老店。南东街上状元楼的双浇面，肉入口即化，酥而不腻，旁边临近桥头的元泰酒店，更是烧得一手当地的名菜，且价钱便宜，不过不是很合我们的胃口，另外我们在古镇门口香聚楼吃的川菜也是非常的不错。

南东街上状元楼，广惠桥边元泰酒。石板小径映斜阳，百间楼前思古贤。

在百间楼东的入口处，还有一家很小的茶店，外面飘着“特色三碗茶”的小旗，我和lalla在吃完状元楼的双浇面回来后路过，好奇的去一窥究竟。所谓三碗茶，一为封哨汤，糯米所制，味甜，一为熏豆茶，熏豆/胡萝卜丁/橘子皮/芝麻等泡制，味咸，一为绿茶，5元一杯，在百间楼河边闲坐慢饮，也别有一番风味。

行人但饮三碗茶，留住江南半缕春

在百间楼，沿河静坐，阳光清洒，微风轻拂，一本旧书，一杯淡茶，浮生半日，世上千年。这样的日子，可惜它又匆匆的结束了。

注：照片都是用Motorola 的Defy所拍，光影魔术手简单的调成了反转片效果，看起来还过得去。

您可能也喜欢：
安昌古镇与乔波冰雪世界	最NB的牺牲，最NB的后续	继续给鲜果抓Bug	Cognos 8 BI中如何实现关联报表	OOW2009美国行:纽约一日游
无觅

MongoDB提供了部分系统的编译版本，但从研究学习以及线上不同依赖包的稳定性的目标，个人还是比较推荐从源代码编译安装的方式。MongoDB的源代码依赖了一些基础组件，如js引擎Spider Monkey，正则表达式引擎PCRE，安装构建工具Scons，以及C++的boost库等，因此编译还是有些麻烦的，realzyy的这篇文章已经比较详细的说明了编译的步骤，主要基于Redhat系统。在ubuntu上安装，还有几个注意点：

1. PCRE最好在编译的时候显式指明对UTF-8的支持

$ configure --enable-unicode-properties
$ sudo make -j 2 && make install

PCRE如果不支持UTF-8，则MongoDB无法启动

Thu Mar 31 17:27:16 Assertion: 10342:pcre not compiled with utf8 support
0x8169528 0x81e704e 0x8450212 0xb73b6ce7 0x80f5b11
 ./mongod(_ZN5mongo11msgassertedEiPKc+0x208) [0x8169528]
 ./mongod(_ZN5mongo6RXTest3runEv+0x3fe) [0x81e704e]
 ./mongod(main+0x3832) [0x8450212]
 /lib/libc.so.6(__libc_start_main+0xe7) [0xb73b6ce7]
 ./mongod() [0x80f5b11]

2. Ubuntu自身带了一个Spider Monkey，但版本有些老，有些MongoDB需要的特性不支持，需要先卸载

$dpkg -l | grep xulrunner
$sudo apt-get remove xulrunner-1.9.2-dev xulrunner-1.9.2

$export CFLAGS=”-DJS_C_STRINGS_ARE_UTF8″
$sudo make -f Makefile.ref
$sudo JS_DIST=/usr make -f Makefile.ref export

3. 需要安装boost等库的支持

$sudo apt-get -y install tcsh git-core scons g++
$sudo apt-get -y install libpcre++-dev libboost-dev libreadline-dev xulrunner-dev
$sudo apt-get -y install libboost-program-options-dev \
libboost-thread-dev libboost-filesystem-dev libboost-date-time-dev

4. 源代码建议从github上下载，根据需要编译相应的版本

$git clone git://github.com/mongodb/mongo.git
$cd mongo
$git tag -l
$git checkout r1.8.0

5.最后，编译安装MongoDB的时候，建议连带头文件和库文件一起

$scons -j 2 all
$scons --prefix=/opt/mongo --full install

另外，MongoDB也可以使用Google V8来作为js引擎，从性能方面来说，V8可能是更好的选择，从jira来看，MongoDB在未来或许会改用v8作为默认引擎。

首先编译V8，然后编译MongoDB的时候使用userv8参数：

$svn checkout http://v8.googlecode.com/svn/trunk/ v8
$cd v8
$scons
$sudo cp libv8.a /usr/lib
$sudo cp libv8preparser.a /usr/lib
$sudo cp -r include/* /usr/include/

$cd mongodb-src
$scons all --usev8
$scons --prefix=/opt/mongo --full install

MongoDB在32位环境下有诸多限制，只能用于学习研究的目的，线上环境一定要使用64位系统。

Thu Mar 31 17:24:58 --oplogSize of 1024MB is too big for 32 bit version. Use 64 bit build instead.

参考：
http://www.mongodb.org/display/DOCS/Building+Spider+Monkey
http://www.mongodb.org/display/DOCS/Building+for+Linux
http://www.howsthe.com/blog/2010/feb/22/mongodb-and-v8/
http://jira.mongodb.org/browse/SERVER-446

您可能也喜欢：
白话MongoDB（三）	NoSQL，关系数据库终结者？	微软亚洲研究院：对联2.0	几张照片	如何监控MemCached的状态
无觅

面向文档，那么什么是文档呢？很明显这不是我们常见的word文档。这里说的文档，是一种可以嵌套的数据集合。从关系数据库的范式的概念来说，嵌套是明显的反范式设计。范式设计的好处是消除了依赖，但是增加了关联，查询需要通过关联两张或者多张表来获得所需要的全部数据，但是更改操作是原子的，只需要修改一个地方即可。反范式则是增加了数据冗余来提升查询性能，但更新操作可能需要更新冗余的多处数据，需要注意一致性的问题。

一个典型的例子，如blog，关系数据库中一般可以把文章设计为一张表，评论设计为一张表，那么在页面需要展示一篇文章和其对应的评论的时候，就需要关联查询文章表和评论表。但是面向文档的设计，可以将评论作为文章的一个嵌套文档存放在一起，这不但省去了关联查询，由于存储在一起，查询的性能也可以做到更好。

MongoDB的面向文档采用的是BSON，一种类似JSON的格式，但是是二进制序列化的。如上面提到的blog的文章和评论，可以做如下设计：

{ 'id':1, 'author':'NinGoo', 'title':'白话MongoDB（一）', 'content':'按照官方的说法，此处省略一万字',
    comment:[ { 'comment-author':'宋兵甲', 'comment-content':'有木有' } ,
              { 'comment-author':'尼玛','comment-content':'伤不起啊' }
            ]
}

1. 相关数据存放在一起，针对性的查询可以消除join，性能比分散存储要高且方便。
2. 整个结构清晰自解析。所有字段名和值都存储，所以不需要提前设计结构，key的名字和数目可以任意指定，也就是所谓的schema-free。
3. 由于字段名在每一行每一列都需要重复存在，会带来一些额外的存储消耗，这在海量数据及字段较多的时候也需要考虑。
4. 一个document的长度有限，1.7.2之前是4MB，目前是8MB，以后可能增长到32MB。如果有更大的数据，可以使用MongoDB底层的GridFS直接作为文件存储。
5. 如果需要查找某个评论者的所有评论，则相对困难。当然，MongoDB支持任意key的索引，这也不是什么大问题。

像上面的一个结构，为一个文档（document），相当于关系数据库中的一行记录，多个文档组成一个集合（collection），相当于关系数据库的表。多个集合（collection），逻辑上组织在一起，就是数据库（database），一个MongoDB实例支持多个数据库（database）。

大部分的NoSQL产品，为追求性能，一致性等，一般只能支持简单的基于row-key的单条或者范围查询，但是MongoDB可以针对任意列的key创建索引，甚至是内嵌文档里的key，从支持的查询的灵活性上来看，更接近传统的关系数据库，同时还能在性能上向NoSQL看齐，加上支持复制，自动分片和Map/Reduce等功能，非常的吸引眼球，正在成为一款热门的海量存储产品。其背后的商业支持公司10gen，也正在不遗余力的推广，前不久还在北京专门组织了一场技术交流会。在其首页列举的典型客户里，包括foursquare，sourceforge，github等知名互联网公司和应用，当然，也包括淘宝网。

您可能也喜欢：
白话MongoDB（二）	白话MongoDB（三）	NoSQL，关系数据库终结者？	Cognos DecisionStream简介(一)	PPLive，网络电视时代来临
无觅

InnoDB的实现更像Oracle，同样是将数据的旧版本存放在单独的回滚段中，但是也有不同。之前还以为整体实现都会跟Oracle不会有太大的出入，也一直没有太在意去看具体实现。今晚晚上下班准备回家时，刚好路过几个同事在交流分享这个问题，遇到一个疑问：

我们知道，InnoDB表会有三个隐藏字段，6字节的DB_ROW_ID，6字节的DB_TX_ID，7字节的DB_ROLL_PTR（指向对应回滚段的地址），这个可以通过innodb monitor看到，当然如果你熟悉innodb文件结构，也可以直接od ibd文件来验证。一致性读主要跟后两者有关系。InnoDB内部维护了一个递增的tx id counter，其当前值可以通过show engine innodb status获得

echo "show engine innodb status\G" | mysql -uroot | grep "Trx id counter"

假设有一个表，当前已经有两条记录。这时候我们开始一个实验，开启两个session，A和B，都设置autocommit=0

MySQL>set global autocommit=0;

T1时间：
A开始一个事务，执行一条select，可以看到已有的两条记录，show engine innodb status可以知道A的tx id，假设为7430
T2时间：
B开始一个事务，执行一条select，可以看到已有的两条记录，可以知道B的tx id，为7431
T3时间：
A中insert一条记录，此时A再select能看到，所以返回三条记录，而B无法看到，还是返回两条记录。
T4时间：
A中执行commit提交事务，分别在A和B中select，得到的结果和T3时间相同。

Ok，假设一致性读是根据事务先后，也就是tx id来比较的话，如果B事务的一致性读是通过B的tx id即7431来和A事务中insert的这条记录的tx id即7430来比较的话，由于A.tx_id < B.tx_id，那么B应该能都到A的记录（tx id是递增的，所以越小说明事务越早开始），但如果能读到，则显然不符合多版本一致性。

因此结果是正确的，那么就是InnoDB的一致性读的实现方式不是像我们按照经验来测试的那样了。通过google和察看代码，原来InnoDB还真是有一个感觉上很山寨的设计，由于tx id是事务一开始就分配的，事务中的变化也没有记录一个类似于Oracle的SCN的逻辑时钟，于是由了如下的实现：

InnoDB每个事务在开始的时候，会将当前系统中的活跃事务列表（trx_sys->trx_list）创建一个副本（read view），然后一致性读去比较记录的tx id的时候，并不是根据当前事务的tx id，而是根据read view最早一个事务的tx id（read view->up_limit_id）来做比较的，这样就能确保在事务B之前没有提交的所有事务的变更，B事务都是看不到的。当然，这里还有个小问题要处理一下，就是当前事务自身的变更还是需要看到的。

有兴趣的可以去仔细看看代码的实现，在storage/innobase/read/read0read.c中实现了创建read view的函数read_view_open_now，在storage/innobase/include/read0read.ic中实现了判断一致性读是否可见的read_view_sees_trx_id。以下代码摘自5.5.8：

UNIV_INTERN
read_view_t*
read_view_open_now(
/*===============*/
	trx_id_t	cr_trx_id,	/*!< in: trx_id of creating
					transaction, or 0 used in purge */
	mem_heap_t*	heap)		/*!< in: memory heap from which
					allocated */
{
	read_view_t*	view;
	trx_t*		trx;
	ulint		n;
	ut_ad(mutex_own(&kernel_mutex));
	view = read_view_create_low(UT_LIST_GET_LEN(trx_sys->trx_list), heap);
	view->creator_trx_id = cr_trx_id;
	view->type = VIEW_NORMAL;
	view->undo_no = 0;
	/* No future transactions should be visible in the view */
	view->low_limit_no = trx_sys->max_trx_id;
	view->low_limit_id = view->low_limit_no;
	n = 0;
	trx = UT_LIST_GET_FIRST(trx_sys->trx_list);
	/* No active transaction should be visible, except cr_trx */
	while (trx) {
		if (trx->id != cr_trx_id
		    && (trx->conc_state == TRX_ACTIVE
			|| trx->conc_state == TRX_PREPARED)) {
			read_view_set_nth_trx_id(view, n, trx->id);
			n++;
			/* NOTE that a transaction whose trx number is <
			trx_sys->max_trx_id can still be active, if it is
			in the middle of its commit! Note that when a
			transaction starts, we initialize trx->no to
			IB_ULONGLONG_MAX. */
			if (view->low_limit_no > trx->no) {
				view->low_limit_no = trx->no;
			}
		}
		trx = UT_LIST_GET_NEXT(trx_list, trx);
	}
	view->n_trx_ids = n;
	if (n > 0) {
		/* The last active transaction has the smallest id: */
		view->up_limit_id = read_view_get_nth_trx_id(view, n - 1);
	} else {
		view->up_limit_id = view->low_limit_id;
	}
	UT_LIST_ADD_FIRST(view_list, trx_sys->view_list, view);
	return(view);
}

UNIV_INLINE
ibool
read_view_sees_trx_id(
/*==================*/
	const read_view_t*	view,	/*!< in: read view */
	trx_id_t		trx_id)	/*!< in: trx id */
{
	ulint	n_ids;
	ulint	i;
	if (trx_id < view->up_limit_id) {
		return(TRUE);
	}
	if (trx_id >= view->low_limit_id) {
		return(FALSE);
	}
	/* We go through the trx ids in the array smallest first: this order
	may save CPU time, because if there was a very long running
	transaction in the trx id array, its trx id is looked at first, and
	the first two comparisons may well decide the visibility of trx_id. */
	n_ids = view->n_trx_ids;
	for (i = 0; i < n_ids; i++) {
		trx_id_t	view_trx_id
			= read_view_get_nth_trx_id(view, n_ids - i - 1);
		if (trx_id <= view_trx_id) {
			return(trx_id != view_trx_id);
		}
	}
	return(TRUE);
}

参考：
http://dev.mysql.com/doc/refman/5.1/en/innodb-multi-versioning.html
http://wangyuanzju.blog.163.com/blog/static/130292009107101544125/
http://bbs.chinaunix.net/thread-1773206-1-1.html

您可能也喜欢：

MySQL InnoDB存储引擎的事务隔离级别

MySQL InnoDB存储引擎的一些参数

InnoDB线程并发检查机制

从show innodb status看XtraDB的增强特性

Innodb monitor介绍

无觅

S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology; sometimes written as SMART) is a monitoring system for computer hard disk drives to detect and report on various indicators of reliability, in the hope of anticipating failures.

When a failure is anticipated by S.M.A.R.T., the drive should be replaced, and can sometimes be returned to the manufacturer, who can use these failed drives to discover where faults lie and how to prevent them from recurring on the next generation of hard disk drives.

Smartmontool是sourceforge上的一个开源项目，可以对磁盘的S.M.A.R.T.进行提取和定期监控。Smartmontool包含两个工具： smartctl和smartd。

$sudo apt-get install smartmontools

Smartctl用于提取和修改硬盘的某些属性和统计信息。Smartd则可以作为守护进程运行，定期收集信息，监控硬盘状态。在我的Thinkpad X200上运行smartctl的结果如下：

ningoo@ning:/sys/block/sda/queue$ sudo smartctl --all /dev/sda
smartctl 5.40 2010-03-16 r3077 [i686-pc-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Device Model:     FUJITSU MJA2320BH G2
Serial Number:    K95DTA52FWAA
Firmware Version: 0084001C
User Capacity:    320,072,933,376 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  ATA-8-ACS revision 3f
Local Time is:    Tue Mar 22 19:14:04 2011 CST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00)	Offline data collection activity
					was never started.
					Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever
					been run.
Total time to complete Offline
data collection: 		 (1009) seconds.
Offline data collection
capabilities: 			 (0x7b) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					Conveyance Self-test supported.
					Selective Self-test supported.
SMART capabilities:            (0x0003)	Saves SMART data before entering
					power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					General Purpose Logging supported.
Short self-test routine
recommended polling time: 	 (   2) minutes.
Extended self-test routine
recommended polling time: 	 ( 143) minutes.
Conveyance self-test routine
recommended polling time: 	 (   2) minutes.
SCT capabilities: 	       (0x003d)	SCT Status supported.
					SCT Error Recovery Control supported.
					SCT Feature Control supported.
					SCT Data Table supported.
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   253   000    Old_age   Always       -       2
200 Multi_Zone_Error_Rate   0x000f   100   100   060    Pre-fail  Always       -       4364
203 Run_Out_Cancel          0x0002   100   100   000    Old_age   Always       -       1533219504675
240 Head_Flying_Hours       0x003e   200   200   000    Old_age   Always       -       0

SMART Error Log Version: 1
ATA Error Count: 1
	CR = Command Register [HEX]
	FR = Features Register [HEX]
	SC = Sector Count Register [HEX]
	SN = Sector Number Register [HEX]
	CL = Cylinder Low Register [HEX]
	CH = Cylinder High Register [HEX]
	DH = Device/Head Register [HEX]
	DC = Device Command Register [HEX]
	ER = Error register [HEX]
	ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 1 occurred at disk power-on lifetime: 1222 hours (50 days + 22 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 03 97 95 a6 00  Error: ABRT

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  00 08 01 01 00 00 00 ff      02:19:49.864  NOP [Reserved subcommand]
  60 08 00 90 95 a6 40 08      02:19:49.862  READ FPDMA QUEUED
  60 10 00 c8 3c a6 40 08      02:19:49.850  READ FPDMA QUEUED
  60 20 00 a8 3c a6 40 08      02:19:49.841  READ FPDMA QUEUED
  60 08 00 88 95 a6 40 08      02:19:49.833  READ FPDMA QUEUED

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

对于使用了RAID卡的硬盘，还需要RAID卡的支持才能读取到磁盘的S.M.A.R.T.信息，同时intel的SSD也将自身的一些健康指标如磨损率等写入了S.M.A.R.T.信息，于是我们就能通过smartctl来获取安装了RAID卡的SSD的寿命等关键指标了。有了这些指标，可以提前预知到SSD的健康状况，对于SSD单点有写入极限这个担忧，就可以稍微降低那么一点，在生产环境中使用也就更有谱了。具体的用法，之前褚霸和B2B的DBA都有写过blog介绍，这里就不展开了，通过MegeCli可以获取LSI的Raid卡的信息（其他Raid卡也有类似的工具）：

sudo  /opt/MegaRAID/MegaCli/MegaCli64 -LdPdInfo -aALL

值得一提的是，SSD的磨损率一般通过E9（233）来获取，也就是Media_Wearout_Indicator指标，是0~100的值，精度还是比较粗的，B2B这边线上用了很久，写入了40TB的测试数据，这个值也还是比较高（99，只少了一滴血，这个boss很难打啊^_^）。如果需要更细粒度的数据，上次Intel的人过来交流的时候，说可以取E2（226 Timed Workload Indicator），E3（227 Timed Workload Read Ratio），E4（(228 Timed Workload Timer）的值来做更高精度的计算，在开始压力测试前，先将对应的E2/E3/E4的值清零

smartctl -t vendor, 0x40 -a /dev/hdx

当然，如果你使用了Riad卡，还是需要配合Raid卡的相应工具才行

smartctl -t vendor,0x40 -d megaraid,30 /dev/sdx

然后执行一次测试(至少60分钟)，重启系统，再次执行smartctl得到E2 = 22， 则该次测试的磨损率为 22 / 1024 / 100= 0.021%（E9的一点血是E2的100点血，也就是说E2的精度比E9高100倍，所以可以在较短时间的测试中看到其变化）。E3 =99 说明读写比例为 99%。该次测试的时间则为E4 = 981分钟，通过计算可以得到该SSD在这样的工作压力下的寿命为E4*1024*100/E2/1440/365 = 8.68年（一年按365天计算）。当然，这个结果是假设这些E2/E3/E4/E9的值都是线性变化的前提下得出的，如果像某些手机的电池指示一样，第一格电可以用一天，最后一格电只能用一个小时，那么这些估算就都是浮云。欲知后事如何，只能等某块SSD用到寿命正常终止，再回头来分析这些指标是否靠谱了。

您可能也喜欢：
用Perl的hash数组实现个性化监控	使用jpgraph绘制数据库监控图形	如何监控MemCached的状态	dstat:一款简单直观的os实时监控工具	使用Oracle正则表达式监控应用到数据库的连接情况
无觅

工作已经过七年多，不知道是不是所谓的七年之痒，今年在一些事情上摇摆不定了很久。好在团队给力，今年数据库整体稳定性上了一个台阶，技术也开始顺畅的华丽转身。也有了更多的时间在工作和生活之间平衡，不再是下班后还是对着电脑敲代码，虽然每天对着电脑的时间依然漫长，却半推半就欲拒还迎的在上下半年有两次的长途旅行。上半年的泰国，下半年的欧洲，有人一路随行，人生不再寂寞。

翻了翻去年元旦，当时雄心满满的To-Do-List，得失参半：

在学习方面，看的技术书很少只是偶尔看看blog，英语除了旅游中多记住了一些常见词依然无起色，杂七杂八的看了基本书也属于过目就忘。至于写书，年头虽然写了几万字，却意兴阑珊的没有坚持下去。

驾照终于到手，报名了一年多，却拖到四月份才去练车，然后又去了泰国旅行，回来考试排到了六月份，好在一气呵成的完成了桩考场考路考，七月份顺利过关，第二周开始开着二手车上路，第三周闯了红灯撞了墙，然后过户，保险，年检，一个多月所有流程打通一遍，囧。

上半年去了一趟泰国，路过一趟吉隆坡。看过安达曼海，从此什么东海南海黄海成浮云。谢谢亲爱的@tb无忧，还有@小LV绿敏小两口，4个人的假期短暂而悠长，逝去的时间短暂，留下的记忆悠长。

下半年领了人生重要一证，去了一趟欧洲。拥挤的香港岛见证，绿色的莫斯科见证，蔚蓝的爱琴海见证，中世纪的布拉格见证，浪漫的巴黎见证，路过的米兰大教堂见证，罢工的雅典见证，人生的里程碑，和@tb无忧 一起完成。人生的道路短暂而悠长，过去的漂泊短暂，未来的依靠悠长。

11月18号，在竹海水韵的小房子交付，后面两个月基本上为装修奔忙，跑遍杭城新时代，第六空间，佳好佳，杭陶，温州村，宏丰，秒遍淘宝，京东，苏宁易购。一个温馨的小家，从无到有开始在慢慢成形。

总体来说，2010收获很多，不管工作还是生活，都完成了180度的大转身。对于2011，其实我已经奢望不多，只是希望，快乐生活。希望我的团队，快乐生活。希望我的朋友们，快乐生活。希望我的家人，快乐生活。希望我自己，快乐生活。

您可能也喜欢：
大年三十，新年快乐	SSD硬盘的IO性能测试	OOW2009美国行:大会第四天	Oracle11g将于7月11号在New York正式发布	我爱北京天安门
无觅

但是，MySQL5.5还是有很多值得期待的特性，其中比较吸引人的，像semi-replication，replication heartbeat，以及partition的可用性提升等。MySQL5.5.8已经将Innodb Plugin1.1.4版本做为内建的Innodb引擎。

MySQL5.5.8源代码编译工具在Linux平台放弃了autotool，而是采用了跨平台的cmake。因此从源代码编译的过程有些不一样。如果系统中没有cmake，还需要先安装：

sudo apt-get install cmake

tar zxvf mysql-5.5.8.tar.gz
cd mysql-5.5.8

CFLAGS="-O3 -g"
CXX=gcc
CXXFLAGS="-O3 -g -felide-constructors -fno-exceptions -fno-rtti"
export CFLAGS CXX CXXFLAGS
cmake -DCMAKE_INSTALL_PREFIX=/opt/mysql -DSYSCONFDIR=/opt/mysql

make -j 2
make install

关于MySQL5.5.8更多cmake选项，请参考文档。

您可能也喜欢：
说说MySQL的在线备份	MySQL的存储引擎	缓存为王：Memcached和MySQL的结合应用	使用MySQL Proxy和MySQL Replication实现读写分离	给MySQL DBA推荐一本书
无觅