NinGoo.net

深入浅出Flashcache（五）

NinGoo — Sat, 14 Jan 2012 00:12:14 +0800

前几天因为测试新版的Flashcache，为了便于监控性能指标，用Perl写了个秒级的监控程序Flashstat，一开始是通过定期获取dmsetup status的信息做解析，后来在flashcache-dev邮件列表中讨论时，Flashcache的作者Mohan Srinivasan说他已经将dmsetup status的信息暴露在/proc/flashcache_stats中，可以更加方便的解析。

实际上，不同版本的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（四）

NinGoo — Tue, 10 Jan 2012 13:38:32 +0800

年底事情比较多，中断了一段时间，这一篇总算要说到Flashcache本身了。由于是内核模块，安装的时候需要内核源码树。具体的安装过程可以参考这里。

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（三）

NinGoo — Sat, 10 Dec 2011 01:50:51 +0800

前文简单介绍了block device和device mapper。有了这两个基础，再来看flashcache的代码，就容易理解多了。Flashcache是一个内核模块，要更清晰的理解代码，还需要了解一下内核模块编写的一些基础知识。好吧，虽然对于内核编程我完全是个门外汉，这里还是需要现学现卖下。所以这一篇还是不会切入正题，已经熟悉Linux内核模块的同学请忽略并耐心等待。

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（二）

NinGoo — Sat, 03 Dec 2011 16:53:42 +0800

前文简单的介绍了block device，别急，虽然这个系列的主要目的是介绍Flashcache，这一篇还是不会切入正题，因为我们还需要先了解下什么是device mapper。

假如一台主机插入了多块硬盘，单块硬盘的容量和性能都是有限的，如果能将多块硬盘组合一个逻辑的整体，对于这台主机来讲，就实现了最简单意义上的“云存储”。有很多方法可以实现这个目的，比如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（一）

NinGoo — Sat, 03 Dec 2011 15:11:14 +0800

Cache is king.

在计算机系统中，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

HBase运维碎碎念

NinGoo — Mon, 27 Jun 2011 15:19:39 +0800

最近开始看HBase，幸运的是，现在HBase社区已经非常的活跃，网络上可以找到大量的参考资料。但对于大集群的运维经验，还有待积累。上周在团队内部简单分享了一下这段时间的读书总结，现在把PPT放出来。

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

Hbase运维碎碎念

View more presentations from seaman ning

关于HBase的一些零碎事

NinGoo — Sat, 18 Jun 2011 10:15:27 +0800

随着Facebook使用HBase来构建实时消息系统，基于Hadoop的面向列存储的HBase持续升温。

目前稳定版本的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过程中的一些零碎的东西，记录于此备忘。

使用RPM&YUM进行基础软件管理

NinGoo — Wed, 25 May 2011 23:15:13 +0800

上周花时间研究了下RPM打包的方法，今天和团队分享了一次。之前我们采用shell脚本进行批量的MySQL安装，虽然通过不断改进的脚本，批量安装部署的效率已经算不错。但即使是安装MySQL这样简单的事情，不断提升效率，在大规模的环境中也是会带来更多的收益。

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

使用Rpm&yum进行基础软件管理

View more presentations from seaman ning

东南亚之旅：越南与柬埔寨（四）

NinGoo — Sat, 23 Apr 2011 01:46:09 +0800

好吧，在胡志明悠闲四天之后，20号我们从Sinh Cafe的大巴开始了紧凑的吴哥窟之旅。对于柬埔寨，以前的唯一印象就是新闻联播中偶有提及的西哈努克国王，首相洪森，以及新闻中不曾提及的那骇人听闻的红色高棉。当然，吴哥窟的大名早已经耳熟能详，但具体如何，则真的是闻名不如见面。这辈子，一定要来看一次吴哥窟，文明的湮灭，在这里有极大的震动，于我而言，远超过雅典卫城和中国长城给我的感觉。如此磅礴的古城，竟然无声无息的消失了四百年多才又重见天日。如此规模的古城，庙宇林立，雕刻精美，残垣断壁，佛兴佛灭，王朝更替，不过寒鸦一声，丛林一片，连历史都不曾有多少记忆。

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同学了，不过鉴于该同学一向的购物欲和价格不敏感，应当肯定是满意的。在吴哥窟各个景点，更是小商贩云集，很多是几岁到十来岁的小孩。虽然柬埔寨的柬语小学是免费的，当地的父母还是更愿意让小孩出来赚美元，或乞讨或贩卖小商品。甚至很多小孩在看见我们都会用中文说，给我糖果。来吴哥窟的中国游客不知道有多少，居然能将当地的小孩训练出流利的普通话乞讨和叫卖。。。

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

东南亚之旅：越南与柬埔寨（三）

NinGoo — Wed, 20 Apr 2011 00:25:34 +0800

说起越南的美食，自然逃不开pho和春卷(spring rolls)。Pho就是越南的米粉，现在杭州有一家pho1000的连锁，虽然不是很地道，偶尔去吃吃也能解解馋，城西在竞舟路文三路口就有一家分店。而春卷分为生春卷和炸春卷，用薄的米皮裹以鲜肉和各类青菜，卷成长条形。米粉和春卷在中国南方很多地方都有，但越南的自有一番不同的风味。杭州西湖体育馆旁边有一家越南餐馆叫火车头，对越南美食有兴趣的朋友，可以过去尝尝。

去年在巴黎，十三区有一家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的三色冰，幸福不需要想太多，往往在太阳快晒晕的时候，一杯廉价清凉的三色冰，幸福便不期而至。

您可能也喜欢：
深入浅出Flashcache（一）	Oracle12G将不再支持裸设备？	压力测试和展示工具Swingbench简介	OOW2009美国行:启程	塔上秋色
无觅

您可能也喜欢：
深入浅出Flashcache（一）	Oracle12G将不再支持裸设备？	OOW2009美国行:宁静安详的波士顿	用Amoeba构架MySQL分布式数据库环境	oracle11g for windows版本发布
无觅

您可能也喜欢：
深入浅出Flashcache（四）	SSD硬盘时代即将到来？	Windows平台不支持32k的block size	SSD硬盘的IO性能测试	Oracle11gR1 for linux x86 64位版本可以下载了
无觅

您可能也喜欢：
深入浅出Flashcache（四）	SSD硬盘时代即将到来？	Windows平台不支持32k的block size	SSD硬盘的IO性能测试	Oracle11gR1 for linux x86 64位版本可以下载了
无觅

您可能也喜欢：
深入浅出Flashcache（四）	SSD硬盘时代即将到来？	Windows平台不支持32k的block size	SSD硬盘的IO性能测试	Oracle11gR1 for linux x86 64位版本可以下载了
无觅

您可能也喜欢：
关于HBase的一些零碎事	Redhat Enterprise Linux 5安装截图欣赏	OOW2009美国行:大会第三天续	车游杭州·疯狂的一天	Cognos Planning安装完成
无觅

您可能也喜欢：
东南亚之旅：越南与柬埔寨（二）	东南亚之旅：越南与柬埔寨（三）	东南亚之旅：越南与柬埔寨（一）	MySQL5.1新特性（一）日志的增强	How to Drill Through from Analysis Studio to Report Studio
无觅