分析ext2文件系统磁盘分区结构

最近看了些kernel fs code, 从实际例子,简单分析一下ext2文件系统的结构,  希望对大家有帮助

本文涉及到一些结构,主要是:

超级块 struct ext2_super_block { }

组描述    struct ext2_group_desc { }

索引节点    struct ext2_inode { }

目录结构    struct ext2_dir_entry_2 { }

1. 准备工作

为了分析,特地格式化了一个100MB左右的ext2文件系统,block size 1024 Bytes

可以看一下这个分区的主要信息:

debugfs:   stats
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          9c0e702c-f80e-4382-a95d-444fafaab34c
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      resize_inode filetype sparse_super
Default mount options:    (none)
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              26104
Block count:              104296
Reserved block count:     5214
Free blocks:              99442
Free inodes:              26091
First block:              1
Block size:               1024
Fragment size:            1024
Reserved GDT blocks:      256
Blocks per group:         8192
Fragments per group:      8192
Inodes per group:         2008
Inode blocks per group:   251
Filesystem created:       Sun Feb 13 22:36:23 2011
Last mount time:          Mon Feb 14 04:49:41 2011
Last write time:          Mon Feb 14 04:49:41 2011
Mount count:              2
Maximum mount count:      34
Last checked:             Sun Feb 13 22:36:23 2011
Check interval:           15552000 (6 months)
Next check after:         Fri Aug 12 22:36:23 2011
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Default directory hash:   tea
Directory Hash Seed:      de62f19c-eaa2-4cb7-a2c6-84fca69baafd
Directories:              2
Group  0: block bitmap at 259, inode bitmap at 260, inode table at 261
           7665 free blocks, 1995 free inodes, 2 used directories

Group  1: block bitmap at 8451, inode bitmap at 8452, inode table at 8453
           7681 free blocks, 2008 free inodes, 0 used directories
Group  2: block bitmap at 16385, inode bitmap at 16386, inode table at 16387
           7939 free blocks, 2008 free inodes, 0 used directories
Group  3: block bitmap at 24835, inode bitmap at 24836, inode table at 24837
           7681 free blocks, 2008 free inodes, 0 used directories
Group  4: block bitmap at 32769, inode bitmap at 32770, inode table at 32771
           7939 free blocks, 2008 free inodes, 0 used directories
Group  5: block bitmap at 41219, inode bitmap at 41220, inode table at 41221
           7681 free blocks, 2008 free inodes, 0 used directories
Group  6: block bitmap at 49153, inode bitmap at 49154, inode table at 49155
           7939 free blocks, 2008 free inodes, 0 used directories
Group  7: block bitmap at 57603, inode bitmap at 57604, inode table at 57605
           7681 free blocks, 2008 free inodes, 0 used directories
Group  8: block bitmap at 65537, inode bitmap at 65538, inode table at 65539
           7939 free blocks, 2008 free inodes, 0 used directories
Group  9: block bitmap at 73987, inode bitmap at 73988, inode table at 73989
           7681 free blocks, 2008 free inodes, 0 used directories
Group 10: block bitmap at 81921, inode bitmap at 81922, inode table at 81923
           7939 free blocks, 2008 free inodes, 0 used directories
Group 11: block bitmap at 90113, inode bitmap at 90114, inode table at 90115
           7939 free blocks, 2008 free inodes, 0 used directories
Group 12: block bitmap at 98305, inode bitmap at 98306, inode table at 98307
           5738 free blocks, 2008 free inodes, 0 used directories

2. 查看 super block

先看超级块,因为第一个block(1024字节)是引导块 ,所以我们从 1024 字节 开始
inode count 等都可以对得上 (注意是little endian)
————————————————————-
struct ext2_super_block {
     __u32     s_inodes_count;          /* Inodes count */ //   f8 65 00 00  = 26140
     __u32     s_blocks_count;          /* Blocks count */  //   68 97 01 00 = 104296
……
    __u16 s_magic;  /* Magic signature */  // ef 53
……
 
[root@ms3003 ~]# dd if=/dev/hdb1 bs=1 count=1024 skip=1024 | od -t x1 -Ax
1024+0 records in
1024+0 records out
000000 f8 65 00 00 68 97 01 00 5e 14 00 00 72 84 01 00
000010 eb 65 00 00 01 00 00 00 00 00 00 00 00 00 00 00
000020 00 20 00 00 00 20 00 00 d8 07 00 00 e5 43 58 4d
000030 e5 43 58 4d 02 00 22 00 53 ef 00 00 01 00 00 00
000040 67 ec 57 4d 00 4e ed 00 00 00 00 00 01 00 00 00
000050 00 00 00 00 0b 00 00 00 80 00 00 00 10 00 00 00
000060 02 00 00 00 01 00 00 00 9c 0e 70 2c f8 0e 43 82
000070 a9 5d 44 4f af aa b3 4c 00 00 00 00 00 00 00 00
000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
……

3. 接下来我们看组描述

再看组描述符 ,32个字节一个,我们可以把debugfs的结果和实际的磁盘信息对照一下

/*
* Structure of a blocks group descriptor
*/
struct ext2_group_desc
{
     __u32     bg_block_bitmap;          /* Blocks bitmap block */
     __u32     bg_inode_bitmap;          /* Inodes bitmap block */
     __u32     bg_inode_table;          /* Inodes table block */
     __u16     bg_free_blocks_count;     /* Free blocks count */
     __u16     bg_free_inodes_count;     /* Free inodes count */
     __u16     bg_used_dirs_count;     /* Directories count */
     __u16     bg_pad;
     __u32     bg_reserved[3];
};


Group  0: block bitmap at 259, inode bitmap at 260, inode table at 261
           7665 free blocks, 1995 free inodes, 2 used directories
Group  1: block bitmap at 8451, inode bitmap at 8452, inode table at 8453
           7681 free blocks, 2008 free inodes, 0 used directories
……

观察磁盘上的信息,都可以对得上
03 01 00 00 = 259
04 01 00 00 = 260
F1 1D          = 7665
cb 07           = 1995
02 00           = 2
03 21 00 00 = 8451
04 21 00 00 = 8452

组描述分布在 super block 后面 (所以从2048开始) ,根据block group数量而有多个,32个字节一组(2行一组),

磁盘100MB,每个block gourp 物理8192KB, 所以有有13个block group, 32*13=0x1A0 , 所以1A0 后面就都是0了

[root@ms3003 ~]# dd if=/dev/hdb1 bs=1 count=1024 skip=2048 | od -t x1 -Ax
1024+0 records in
1024+0 records out
000000 03 01 00 00 04 01 00 00 05 01 00 00 f1 1d cb 07
000010 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000020 03 21 00 00 04 21 00 00 05 21 00 00 01 1e d8 07
000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000040 01 40 00 00 02 40 00 00 03 40 00 00 03 1f d8 07
000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000060 03 61 00 00 04 61 00 00 05 61 00 00 01 1e d8 07
000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000080 01 80 00 00 02 80 00 00 03 80 00 00 03 1f d8 07
000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000a0 03 a1 00 00 04 a1 00 00 05 a1 00 00 01 1e d8 07
0000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000c0 01 c0 00 00 02 c0 00 00 03 c0 00 00 03 1f d8 07
0000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000e0 03 e1 00 00 04 e1 00 00 05 e1 00 00 01 1e d8 07
0000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000100 01 00 01 00 02 00 01 00 03 00 01 00 03 1f d8 07
000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000120 03 21 01 00 04 21 01 00 05 21 01 00 01 1e d8 07
000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000140 01 40 01 00 02 40 01 00 03 40 01 00 03 1f d8 07
000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000160 01 60 01 00 02 60 01 00 03 60 01 00 03 1f d8 07
000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000180 01 80 01 00 02 80 01 00 03 80 01 00 6a 16 d8 07
000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
000400

4. 查看根目录的inode
 
ext2 根目录的inode number = 2 ,所以这个inode 在 group 0  , 是第二个inode
Group  0: block bitmap at 259, inode bitmap at 260, inode table at 261
每个 inode 是一个 struct ext2_inode , 128 个字节,所以磁盘上的偏移就是 261*1024 + 128 = 267392
 
[root@ms3003 ext2]# dd if=/dev/hdb1 bs=1 count=256 skip=267392 | od -t x1 -Ax  
256+0 records in
256+0 records out
000000 ed 41 00 00 00 04 00 00 52 13 5b 4d e1 82 58 4d
000010 e1 82 58 4d 00 00 00 00 00 00 03 00 02 00 00 00
000020 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00
000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

i_mode = 0x41ed = 0040755 (8进制 ) , 也就是 目录 + 755 权限(drwxr-xr-x)

block 索引第一个是 00 02 ,就是512块

对照 struct ext2_inode ,

 {
 __u16 i_mode;  /* File mode */
 __u16 i_uid;  /* Low 16 bits of Owner Uid */
 __u32 i_size;  /* Size in bytes */

……

__u32 i_block[EXT2_N_BLOCKS];/* Pointers to blocks */ 从40个字节处开始

…..

}

5. 查看根目录的目录结构

我们看一下根目录有哪些文件(目录是特殊的文件),和磁盘分区信息对照一下
注意最左边的数字是inode number
[root@ms3003 ext2]# ll -ia
total 23
     2 drwxr-xr-x  3 root root  1024 Feb 14 09:18 .
812001 drwxr-xr-x  4 root root  4096 Feb 13 22:36 ..
    11 drwx——  2 root root 12288 Feb 13 22:36 lost+found
    15 -rw-r–r–  1 root root    72 Feb 14 09:18 test
    12 -rw-r–r–  1 root root    69 Feb 13 22:45 test2

[root@ms3003 ext2]#  dd if=/dev/hdb1 bs=1024 count=1 skip=512 | hexdump -C
1+0 records in
1+0 records out
00000000  02 00 00 00 0c 00 01 02  2e 00 00 00 02 00 00 00  |…………….|
00000010  0c 00 02 02 2e 2e 00 00  0b 00 00 00 14 00 0a 02  |…………….|
00000020  6c 6f 73 74 2b 66 6f 75  6e 64 00 00 0c 00 00 00  |lost+found……|
00000030  10 00 05 01 74 65 73 74  32 2e 73 77 0f 00 00 00  |….test2.sw….|
00000040  c4 03 04 01 74 65 73 74  74 65 73 74 00 00 00 00  |….testtest….|
00000050  b4 03 09 01 2e 74 65 73  74 2e 73 77 70 70 00 00  |…..test.swpp..|
00000060  00 00 00 00 a0 03 05 01  74 65 73 74 7e 2e 73 77  |……..test~.sw|
00000070  70 78 78 00 00 00 00 00  00 00 00 00 00 00 00 00  |pxx………….|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |…………….|

对照 ext2_dir_entry_2 分析,注意 这是个可变长度的结构,长度为rec_len , 而名字长度为 name_len
struct ext2_dir_entry_2 {
     __u32     inode;               /* Inode number */
     __u16     rec_len;          /* Directory entry length */
     __u8     name_len;          /* Name length */
     __u8     file_type;
     char     name[EXT2_NAME_LEN];     /* File name */
};

蓝色和红色分别是目录  .  和 .. inode id = 2
绿色是 lost+found , inode id = 11 (0b 00 00 00)
紫色是 test2     , inode id = 12 (0c 00 00 00)
深黄色 是 test     , inode id = 15 (0f 00 00 00)

该块信息和 ext2 根目录文件都可以对应上

6.查看普通文件 test 的内容

test 文件的 inode 是 15,那么我们计算一下它的inode的位置, 是group 0 的 第15个inode, 磁盘偏移是

261*1024 + 128*14 = 269056

[root@ms3003 ~]# dd if=/dev/hdb1 bs=1 count=256 skip=269056 | od -t x1 -Ax      
256+0 records in
256+0 records out
000000 a4 81 00 00 48 00 00 00 df 0d 5b 4d e1 82 58 4d
000010 e1 82 58 4d 00 00 00 00 00 00 01 00 02 00 00 00
000020 00 00 00 00 00 00 00 00 09 14 00 00 00 00 00 00
000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

我们找到这个 inode , imode = 0x81a4 = 00100644 (8进制 ) , 也就是普通文件+权限644(-rw-r–r– )

第一个block号码是 0x 14 09 = 5192

那我们查看一下 5192 block 的内容, 和 cat test 的结果是一致的

[root@ms3003 ext2]# cat test
apeonaaaaaaaaaaaaaaaaaaab
bbbbbbbbbbbbbbbbbbbb
ccccccccccccccccccc:q!
\

[root@ms3003 ~]# dd if=/dev/hdb1 bs=1024 count=1 skip=5129 | od -t x1 -aAx
1+0 records in
1+0 records out
000000 61 70 65 6f 6e 61 61 61 61 61 61 61 61 61 61 61
         a   p   e   o   n   a   a   a   a   a   a   a   a   a   a   a
000010 61 61 61 61 61 61 61 61 62 0a 62 62 62 62 62 62
         a   a   a   a   a   a   a   a   b  nl   b   b   b   b   b   b
000020 62 62 62 62 62 62 62 62 62 62 62 62 62 62 0a 63
         b   b   b   b   b   b   b   b   b   b   b   b   b   b  nl   c
000030 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63
         c   c   c   c   c   c   c   c   c   c   c   c   c   c   c   c
000040 63 63 3a 71 21 0a 5c 0a 00 00 00 00 00 00 00 00
         c   c   :   q   !  nl   \  nl nul nul nul nul nul nul nul nul
000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul

 

菊子曰 本文用菊子曰发布
Posted in 未分类 | Leave a comment

CDN Origin Pull

Origin Pull 这个技术其实说起来也不算什么新鲜玩意,大致就是 PULL from Original Server 的意思。 内容自动的从源站点传输到CDN之中,这个和手工的上传内容相对应。

比如一个域名: www.duba.net , 它的CNAME是 www.duba.net.cachecn.com , 我们访问页面,其中有首页的图标, 浏览器请求logo图片 http://www.duba.net/v5/images/logo.jpg ,

CNAME 的 解析 IP 指向一个CDN缓存服务器, CDN检查该 v5/images/logo.jpg 是否存在于CDN, 和内容的Fresh情况, 假如内容不存在或者过期,  就从CNAME关联的源服务器(CDN系统配置的)自动获取内容,这里可能是  http://www.duba.net , 或者是 image.duba.net/logoimage ( 比如 http://image.duba.net/logoimage/v5/images/logo.jpg )也说不定.

这个和常见的反向代理cache差不多。

源服务器要适当的设置 HTTP 的 cache 头,  用来供CDN控制刷新时间。没有的话,CDN会有缺省配置。

一般来说,CDN也允许手工设置刷新时间。

 

 

 

 

菊子曰 本文用菊子曰发布
Posted in 未分类 | Leave a comment

牛项目 Harvest

昨晚看《A Hierarchical Internet Object Cache》的时候,看到paper里面吹Harvest是如何的牛,就google了一下,还真的很牛:

  • Harvest 后来发展成了大名鼎鼎的 Squid
  • Netcache 产品也是 based on Harvest (netcache 曾经是如雷贯耳的 netapp 产品,,后来卖给了 blue coat )
  • Harvest 的作者之一(也是paper作者之一), Chunk Neerdaels , 目前在Akamai做VP

基本上算是 Caching / CDN 产业的源头项目(还是加个”之一”吧)了啊!

菊子曰 本文用菊子曰发布
Posted in 未分类 | Leave a comment

CDN设计:[笔记]Analysis of Enterprise Media Server Workloads

这里主要是对paper的笔记,和一些将访问模式应用到实际video CDN系统设计的考虑

【Key new observations】

  • with 77-79%of media sessions being less than 10 min long, 7-12% of the sessions being 10-30 min, and 6-13% ofsessions continued for more than 30 min.

对于对象的cache有两种选择:全部缓存,和部分缓存。部分缓存比完整对象复杂得多,但是看看它能够带来的好处: 有不少的session都是很短的,这里10分钟以下的session达到了77%以上,这样,对于影片之类的大对象的部分缓存,就意味着更加的节省cache资源,而且使用有限的空间,可以得到更高的命中率

  • Most of the incomplete sessions (i.e. terminated by clients before the video was fnished) are accessing the initial segments of media file.

缓存影片头部比缓存整个片子更加划得来,特别是对于冷片,访问头部的session会更多(看了开头就不想看了)

  • high locality of accesses: 14-30% of the files accessed on the server account for 90% of the media sessions

这里都是常识了,常见的20/80规律,不过有些人居然把20/80一个定性的东西当成一个定量的指标就比较杯具了

  • there is a significant number of files that are rarely accessed (16% to 19% of the files are accessed only once)

对于这些影片如何优化cache,是一个可以提高的地方,关键是这部分影片的比例有多少。

  • Zipf Like distribution

这个我也统计过,参见这里(http://blog.lmtw.com/b/peon/archives/2006/39703.html)

IPTV几个site都是a=0.6左右,比paper的a值低很多。这种情况下,20的内容只能覆盖50的sessions

  • Accesses to the new files constitute most of the accesses in any given month

paper里面的enterprise环境会加剧这个倾向,毕竟一些企业的多媒体对象实时性很强,和新闻差不多。但是对于IPTV影视,这个也是成立的。可惜我这里没有更好的数据。一些site会缺省的把新片做一个PUSH,这是值得提倡的

  • For both workloads, 51-52% of accesses to media files occur during the first week of their introduction.

说明大部分新片也会很快变冷,这个充分说明了我2002做的时间加权算法的优越性了,否则统计一个时间窗或者是累计点击次数,都是对于影片的冷热变化趋势不够敏感的

————————————————————————————

  • 访问时长

  • Zipf统计图

  • New Files 访问占一个月访问的比例

 

 

菊子曰 本文用菊子曰发布
Posted in 未分类 | Leave a comment

可惜了,Windows Live Sync 2011年会停止服务了

最近设置live sync的时候,发现说2011会停止服务,真的觉得很遗憾。

我从FolderShare(这个软件被微软收购前的名字) 的时代就开始使用,用于多台计算机文件的同步。后来用过Dropbox,也用过DBank等国产的服务,但是觉得LiveSync这样不需要网络存储,直接多机p2p同步的软件是非常有用的。 微软虽然不是很高调,还是实打实做了一些不错的网络服务。

Live Sync 将会被 Live Mesh代替,但是Live Mesh不能用于windows xp,另外带网络存储的方式也有些慢,有存储限制,而且让人觉得不够安全。

The Sync website will soon stop working

Windows Live Mesh 2011 is replacing Windows Live Sync, and new users can’t download Sync anymore. In early 2011, this website will be shut down and your files will stop syncing. Learn more about Windows Live Mesh 2011 and how to upgrade.
Posted in 未分类 | Leave a comment

解决电脑双击文件反应慢的问题

我的笔记本装的是 windows xp 专业版本,好长一段时间以来,都出现一些问题:

  1. 双击打开文件反应很慢,等很久
  2. 文件上点击右键非常慢,等很久
  3. "我的电脑"点击空白的地方右键,新建菜单很久才能出来,甚至"我的电脑"就死掉了

网上找了很多,没有答案。

前段时间,将电脑里面各色软件安装的插件卸载了很多,忽然发现问题没有了,很高兴,结果从公司拿回家,问题依旧,看来不是这些插件带来的问题。公司是在办公网络里面,家里当然就不能在公司内网工作了,这也许是个原因吧。发现这点后,我发现在公司使用果然这个问题不那么明显,回家使用笔记本问题就比较明显。不过电脑一直没有装抓包工具,暂时没有去管。

今早在家,"我的电脑"又死掉几次,实在难以忍受了,我想到:

1.也许双击文件的时候,windows干了一些莫名其妙的事情,不过没有办法看到

2.在公司使用就OK,在家使用就慢,和公司家里的环境有关,一方面是windows域的可能,另外的可能是网络访问的问题

那么二话不说,打开Ethreal ,双击一个txt文件的时候抓包,看看发生了什么:

发现双击txt文件以后,存在一些网络通信,有解析 sz-file-svr (公司的某台服务器) 的,而且解析不成功,我想,到底双击文件的时候,windows想干什么呢?没有理由去 sz-file-svr 打开什么东西啊?难道公司用间谍软件将我们的操作发到什么地方(呵呵,真黑啊)?

不过还是修改 host 文件,人工加上该名字解析,发现问题照旧。

继续抓包,用工具看不到这些网络通信的进程信息,看来这些包是windows底层发出的,和应用进程没有什么关系,都是一些 microsoft-ds 还有 NBSTAT 之类的query,不知道到底发生了什么。我想到,假如和公司网络相关,也许我应该登录公司网络看看发生了什么,登录公司网络后,用ethreal抓包并双击文件,这下发现好几个 SMB 通信(就是微软的共享文件访问的),指向一个 \\sz-file-svr\\FlashCS4\flash.exe 文件,

 image

看来windows试图对 flash.exe 进行什么操作,查了一下,注册表里面很多和 flash.exe 的信息,我想起来,以前下载了一个绿色版的 flash cs4 放到服务器上,而且在服务器上直接运行了,看来这个软件没有这么绿色,留下来很多东西,在家里用的时候, windows 试图访问类似于图标还有打开程序这类信息,结果导致系统出现了很多问题。

打开 regedit ,将该 flash 程序的信息删除,问题解决了!看来下次得注意,不能从外部服务器上运行“绿色软件”了。

Posted in 未分类 | Tagged | 1 Comment

{讨论}技术的平等和民主

 

看了云风的文章《平等》 , 谈到一个公司文化的平等的氛围问题,其实很多公司,都不会X总,X经理的喊,甚至经理也不会有单独的办公室,而是和大家坐在一起。这些都是不难做到的,关键是把平等贯彻到日常的行为里面。比如:当双方分歧很大的时候, 怎么做最后的决定?云风很反对按照级别或者资历之类的东西来做准则。云风提到:

04 年,我和我的上司 dingdang 有过一次激烈的争吵。那是唯一的一次。谁都说服不了谁。最后 dingdang 逼急了,说,这次一定要听我的,我要为整个团队负责。一句话噎的我在旁边闷声不响。五分钟以后,dingdang 就跑过来向我道歉。或许,有人不会理解,为什么应该道歉?因为,无论你看的多远,想的更多,在讨论具体问题时,不能以自己的位置来压人。其实,这个位置不单单是指职位的高低,也包含有你的经验,你在行业内的权威,等等。

很多技术讨论,并非很明显的1+1=2的,特别是设计来讲,只是一个根据各种因素的折中,而这些因素的权重,却需要根据不完整的信息做判断,这就类似于下面的情况:两个feature都很重要,但是资源不够,砍掉哪个?

另外的有些事情,明显就是公说公有理,婆说婆有理,比如选择哪个代码风格的问题,永远也不会有个结果。

很多时候是需要下决断的,很多时候,并非最优的判断比没有判断好,大家一般用什么途径来决断的?

 

其实我觉得dingdang的做法是对的,只是话有那么些刺耳。

我的想法是,领导有责任引导大家达到一致,但是假如不能的话,谁对这个事情负责,谁就有责任下决断,这个责任会更多的落到Leader/Manager或者架构师、资深工程师的头上。

换个说法,就是"我会听取大家的意见,但是假如无法决议的话,最后得听我来判断", 听起来没有那么舒服也没有那么民主了?大家怎么看?

Posted in 未分类 | Tagged | 2 Comments

[笔记] Darwin Streaming server 的 Task 类

这是我在另外一个blog的老文: http://blog.lmtw.com/b/peon/archives/2007/48655.html

 

Darwin Streaming Server 是一个开放源代码的streaming server,对于streaming server的编程和软件结构有着一定的参考价值,它是使用C++写的,其中的并发模式的核心就是Task类,下面写一下我的理解:

多任务的程序常常采用线程+同步阻塞IO的模式, 每个线程/进程服务于一个client,使用阻塞式的IO:

这种模式对于交互式的长连接应用也是常见的选择(比如Telnet)。好处是实现极其简单,容易嵌入复杂的交互逻辑。Apache、ftpd 等都是这种工作模式。但是这种策略很能难足高性能程序的需求。

在handle大量用户的情况下,为了避免创建过多的线程导致context switch开销,常常采用select I/O复用的方法(你可能说select过时了,不过Darwin QTSS就是用的这个, 说实话,这个框架的IO部分确比不上libevent/ACE):

上面是经典的select IO复用的过程, 以上的过程可以由3步来描述:

  1. 应用注册事件

  2. 事件触发通知应用

  3. 应用运行处理事件

注意在SELECT THREAD有3个任务:接受事件注册,等待事件触发,驱动SESSION处理事件,这些任务可以分解为不同的角色,我们可以在这种模式里定义4种角色:

1. EventHandler : EventHandler 向 EventGenerator注册事件,并对注册事件进行处理

2.EventGenerator :EventGenerator接受事件注册,当事件触发的时候,通知 EventHandler

3.EventHandler Driver : EventHandler Driver 驱动EventHandler 的运行,当它发现有 EventHandler 受到事件触发以后,调度运行 EventHandler 的事件处理函数。一个EventHandler Driver可以驱动多个EventHandler。多个EventHandler Driver可以组成 Pool 进行驱动EventHandler。

4. Event Driver : Event Driver 驱动 EventGenerator 的事件触发。EventGenerator本身不包含执行线程,需要Event Driver的驱动。多个EventGenerator 在 Event Driver 中等待事件,当事件发生时,Event Driver调度 EventGenerator的来触发事件。

下面就是Darwin对各个对象和上述角色的对应:

  1. Task 就是对EventHandler的对象化封装。每个Task对象有两个主要的方法:Signal和Run。当服务器希望发送一个事件给某个Task对象时,就会调用Signal()方法;而Run()方法是在Task对象获得处理该事件的时间片后运行的,服务器中的大部分工作都是在不同Task对象的Run()函数中进行的。每个Task对象的目标就是利用很小的且不会阻塞的时间片完成服务器指定某个工作。应用可以通过继承Task 并重写Run()方法实现自己的任务。

  2. EventContext 对应EventGenerator的角色,事件的触发者,当事件发生时,调用Task::signal().

  3. TaskThread 对应EventHandler Driver的角色。任务的驱动线程,对一个或者多个Task进行调度,通过调用 Task::run() 处理事件

  4. EventThread对应Event Driver的角色。EventContext的驱动线程,可以处理多个EventContext, 发生事件时调用EventContext::process_event(),后者将调用Task::Signal()

流程:

  1. Client或者 Task的子类向Event Context注册事件。

  2. Event Context将事件放入EventThread的Pool内。

  3. EventThread 调用select 等待多个事件中任一个触发。

  4. 事件触发以后,EventThread调用 Event Context::process_event()。

  5. 调用 Task::signal()。

  6. Task::signal()将task放入TaskThread的队列。

  7. TaskThread调度相应的Task, 执行其Run()方法。

Posted in 未分类 | Tagged , | 2 Comments

关于Youtube 的平均文件尺寸与GFS

Google的Sean Quinlan 最近提到老的的GFS设计已经不适合Google的一些新应用,包括youtube. 除了单metaserver以外,其他的方面暂时还想不到 GFS 在 youtube 上出了什么问题。比如 GFS 的大文件假设?

其实在我的感觉里,youtube文件应该尺寸不小?不过查一下google吧, 有一份07年末的数据:

http://www.websiteoptimization.com/speed/tweak/average-web-page/

In 1997, 90% of videos were under 45 seconds in length (Acharya & Smith 1998). In 2005, the median video was about 120 seconds long (Li et al. 2005). By 2007, the median video was 192.6 seconds in duration (Gill et al. 2007). The median bit rate of web videos grew from 200Kbps in 2005 to 328Kbps on YouTube in 2007. So by late 2007, the median video weighed in at over 63MB in file size. On YouTube, the average video size is 10MB, with over 65,000 new videos added every day.

在2007年末,Youtube 平均文件尺寸是10MB,这个也解释了 the assumption of GFS 在youtube上碰到了一些问题的原因,我想我大概是只在土豆上看电影,搞得以为文件都是大于60MB的。其实 youtube 上短片还是短片居多,但是我还是疑惑,按理来说,视频文件的尺寸增长应该是极为迅速的,今天文件小了点,以后就会足够大了。你看youtube不是将上传的限制提升到2GB了么?

另外,还有一个资料也不错,老了点,仅供参考吧

http://tech.163.com/09/0305/22/53M4VD3D000915BF.html

http://www.pbdigg.net/show/14773.html

comScore的报告还显示,今年10月网络视频的平均播放时间为3.0分钟。Hulu视频的平均播放时间为11.6分钟,高居各大网络视频公司榜首。
comScore的报告内容还包括:
·77%的美国网络受众观看网络视频。
·每个网络视频观看者每月观看274分钟的视频。
·超过80%的18岁至34岁的年轻人观看网络视频。18岁至34岁的年轻人每月收看4.8小时的网络视频。
·YouTube的单一访问用户达到9950万人,他们收看了53亿次视频,平均每个用户收看53.2个视频。
·MySpace的单一访问用户达到5120万人,平均每个用户收看8.0个视频。
·每段视频的平均播放时间为3.0分钟。
·Hulu视频的平均播放时间为11.6分钟,高居各大网络视频公司榜首。

 

牢骚一下,twitter/youtube 国内都访问不了,google.com经常打不开,查个资料还经常“载入页面时到服务器的连接被重置”,多半是被墙了,真的挺没劲。

Posted in 未分类 | Tagged | Leave a comment

4.4-bsd-lite source download (源代码下载)

《TCP/IP详解》(TCP/IP Illustrated) 很多人都在看,<卷2:实现>  里面参考的代码是 4.4bsd-lite 的 source code,这个代码也有不少人找,因为书上给的下载url早就不能用了:(

从网上下载来,给大家共享一下:

4.4BSD-lite.tar.gz  http://www.mybloop.com/go/rXjhH7

4.4BSD-lite2.tar.gz  http://www.mybloop.com/go/n272eK

顺便缅怀一下 W.Richard Stevens ,太牛了。

一个人写本书容易,难得是几本书都好得不能再好,万人景仰,这才是最难最难的啊!

把那几本书翻烂先!

Posted in 未分类 | Leave a comment