As well as from fdisk output, it said,

From his observation, before format the SSD, there was 78654240 1k blocks available on the partition, after the format, 77418272 1k blocks could be used, which means almost 1G space unused from the partition.

A more serious question was, from the output of df, used blocks + available blocks = 73485560, but the file system had 77418272 blocks — 4301144 1k blocks disappeared ! This 160G SSD costs him 430USD, he complained around 15USD was payed for nothing.

IMHO, this is a quite interesting question, and asked by many people for many times. This time, I’d like to spend some time to explain how the blocks are wasted, and how to make better usage of every block on the SSD (since it’s quite expensive).

First of all, better storage usage depends on the I/O pattern in practice. This SSD is used to store large file for random I/O, especially most of the I/O (99%+) is reading on random file offset, the writing can almost be ignored. Therefore, it is wanted to use every available block to store a very big files on the Ext3 file systems.

If only using the default command line to format an Ext3 file system like “mkfs.ext3 /dev/sdb1″, mkfs.ext3 will do the following things for block allocation,

- Allocates reserved blocks for root user, to avoid non-privilege users using up all disk space.

- Allocates metadata like superblock, backed superblock, block group descriptors, block bitmap for each block group, inode bitmap for each block group, inode table for each block group.

- Allocates reserved block group blocks for offline file system extension.

- Allocates blocks for journal

Since the SSD is only for data storage, no operation system installed on it, and writing performance is disregarded here, and no requirement for further file system size extension, and only a few files are stored on the file systems, some blocks allocation is unnecessary and useless,

- Journal blocks

- Inodes blocks

- Reserved group descriptor blocks for file system resize

- Reserved blocks for root user

Let’s run dumpe2fs to see how many blocks are wasted on the above items, I only list part of the output (outlines) here,

> dumpe2fs /dev/sdb1

Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          f335ba18-70cc-43f9-bdc8-ed0a8a1a5ad3
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              4923392
Block count:              19663560
Reserved block count:     983178
Free blocks:              19308514
Free inodes:              4923381
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1019
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Filesystem created:       Tue Jul  6 21:42:32 2010
Last mount time:          Tue Jul  6 21:44:42 2010
Last write time:          Tue Jul  6 21:44:42 2010
Mount count:              1
Maximum mount count:      39
Last checked:             Tue Jul  6 21:42:32 2010
Check interval:           15552000 (6 months)
Next check after:         Sun Jan  2 21:42:32 2011
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      3ef6ca72-c800-4c44-8c77-532a21bcad5a
Journal backup:           inode blocks
Journal features:         (none)
Journal size:             128M
Journal length:           32768
Journal sequence:         0×00000001
Journal start:            0

Group 0: (Blocks 0-32767)
Primary superblock at 0, Group descriptors at 1-5
Reserved GDT blocks at 6-1024
Block bitmap at 1025 (+1025), Inode bitmap at 1026 (+1026)
Inode table at 1027-1538 (+1027)
31223 free blocks, 8181 free inodes, 2 directories
Free blocks: 1545-32767
Free inodes: 12-8192

[snip ....]

The file system block size is 4KB, which is different from the output block size of df and fdisk. In the above output, I mark the outlines with RED color. Now let’s look at the line for reserved block,

Reserved block count:     983178

These 983178 4K blocks are served for root user, since the system and user home is not on SSD, we don’t need to reserve these blocks.  Read mkfs.ext3(8), there is a parameter ‘-m’ to set reserved-blocks-percentage, set ‘-m 0′ to reserve zero block for privilege user.

From file system features line, we can see resize_inode is one of the default enabled feature,

Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file

resize_inode feature reserves quite a lot blocks for new extended block group descriptors, these blocks can be found from lines like,

Reserved GDT blocks at 6-1024

When resize_inode feature enabled, mkfs.ext3 will reserve some blocks after block group descriptor blocks, called “Reserved GDT blocks”.  If file system will be extended in future (e.g. the file system is created on a logical volume), these reserved blocks can be used for new block group descriptors. Now the storage media is SSD, not file system extension in future, we don’t have to pay money (on SSD, blocks means money) for this kind of blocks. To disable resize_inode feature, use “-O ^resize_inode” in mkfs.ext3(8).

Then look at these 2 lines for inode blocks,

Inodes per group:         8192
Inode blocks per group:   512

We only store no more than 5 files on the whole file systems,  but here 512 blocks in each block groups are allocated for inode table. There are 601 block groups, which means 512×601=307712 blocks (≈ 1.2GB space) wasted for inode tables.  Using ‘-N 16′ in mkfs.ext3(8) to specify only 16 inodes in the file system, though mkfs.ext3(3) at least allocate one inode table block in each block group (more then 16 inodes), we only wast 1 block other than 512 blocks for inode able now.

Journal size:             128M

If most of the I/O are readings while writing performance is ignored, and people are really care about space usage, the journal area can be reduced to minimum size (1024 file system blocks), for 4KB blocks Ext3, it’s 4MB: -J size=4M

By above efforts, there is around 4GB+ space back to use. If you really care about the space usage efficiency of your SSD, how about making the file system with:

mkfs.ext3 -J size=4M -m 0 -O ^resize_inode -I 16  <device>

Then you have chance to get more data blocks into usage on your expensive SSD

Today, Taobao announces its open source community  — http://code.taobao.org.

This is a historical day, a China local  internet and e-business leading company joins open source world by its practice approved activity.

The first project released on code.taobao.org is TAIR. Tair is a distributed, high performance key/value storage system, using in Taobao’s infrastructure for time.  Taobao is on the way to make more internal projects to be open source. Yes, talk is cheap, show the code !

If you are working on large scale website, with more than 10K server nodes, checking projects on code.taobao.org may help you to avoid making another wheel. Please, visit http://code.taobao.org, and join the community to contribute. I believe people can improve the community better and better. Currently, most of the expect developers are Chinese spoken, that’s why you can find square characters on the website. I believe more changes will come in future, because the people behind the community like continuously improvement

Of cause there are some other contributions to open source community from Taobao can not be found on code.taobao.org, For example, I believer patches from Taobao will appear in Linux kernel changelog very soon

Their choice is reasonable,

1, Random I/O on large file cannot get any help from file system page cache.

2, <logical offset, physical offset> mapping introduces more I/O on file systems than on raw disk

3, Managing metadata on other powerful servers avoid the necessary to use file systems for data nodes.

The penalty for the “higher” performance is management cost, storing data on raw device introduces difficulties like,

1, Harder to backup/restore the data.

2, Cannot do more flexible management without special management tools for the raw device.

3, No convenient method to access/management the data on raw device.

The above penalties are hard to be ignored by system administrators. Further more, the store of “higher” performance is not exactly true today,

1, For file systems using block pointers for <logical offset, physical offset> mapping, large file takes too many pointer blocks. For example, on Ext3, with 4KB block, a 2TB file needs around 520K+  pointer blocks. Most of the pointer blocks are cold in random I/O, which results lower random I/O performance number than on raw device.

2, For file systems using extent for <logical offset, physical offset> mapping, the extent blocks number depends on how many fragment a large file has. For example, on Ext4, with max block group size 128MB, a 2TB file has around 16384 fragment. To mapping these 16K fragment, 16K extent records are needed, which can be placed in 50+ extent blocks. It’s very easy to hit a hot extent in memory for random I/O on large file.

3, If the <logical offset, physical offset> mapping can be cached in memory as hot, random I/O performance on file system might not be worse than on raw device.

In order to verify my guess, I did some performance testing.  I share part of the data here.

Processor: AMD opteron 6174 (2.2 GHz) x 2

Memory: DDR3 1333MHz 4GB x 4

Hard disk: 5400RPM SATA 2TB x 3 [2]

File size: (create by dd, almost) 2TB

Random I/O access: 100K times read

IO size: 512 bytes

File systems: Ext3, Ext4 (with and without directio)

test tool: seekrw [3]

* With page cache

- Command

seekrw -f /mnt/ext3/img -a 100000 -l 512 -r

seekrw -f /mnt/ext4/img -a 100000 -l 512 -r

- Performance result

	Device	tps	Blk_read/s	Blk_wrtn/s	Blk_read	Blk_wrtn
Ext3	sdc	95.88	767.07	0	46024	0
Ext4	sdd	60.72	485.6	0	29136	0

- Wall clock time

Ext3: real time: 34 minutes 23 seconds 557537 usec

Ext4: real time: 24 minutes 44 seconds 10118 usec

* directio (without pagecache)

- Command

seekrw -f /mnt/ext3/img -a 100000 -l 512 -r -d

seekrw -f /mnt/ext4/img -a 100000 -l 512 -r -d

- Performance result

	Device	tps	Blk_read/s	Blk_wrtn/s	Blk_read	Blk_wrtn
Ext3	sdc	94.93	415.77	0	12473	0
Ext4	sdd	67.9	67.9	0	2037	0
Raw	sdf	67.27	538.13	0	16144	0

- Wall clock time

Ext3: real time: 33 minutes 26 seconds 947875 usec

Ext4: real time: 24 minutes 25 seconds 545536 usec

sdf: real time: 24 minutes 38 seconds 523379 usec    (raw device)

From the above performance numbers, Ext4 is 39% faster than Ext3 on random I/O with or without paegcache, this is expected.

The result of random I/O on Ext4 and raw device, is almost same. This is a result also as expected. For file systems mapping <logical offset, physical offset> by extent, it’s quite easy to make most of the mapping records hot in memory. Random I/O on raw device has *NO* obvious performance advance then Ext4.

Dear developers, how about considering extent based file systems now

—

[1] TFS, TaobaoFS. A distributed file system deployed for http://www.taobao.com . It is developed by core system team of Taobao, will be open source very soon.

[2] The hard disk is connected to RocketRAID 644 card via eSATA connecter into system.

[3] seekrw source code can be download from http://www.mlxos.org/misc/seekrw.c

Mark gave a simplified explanation on NL, PR and EX dlm lock levels used in OCFS2.

There are 3 lock levels Ocfs2 uses when protecting shared resources.

“NL” aka “No Lock” this is used as a placeholder. Either we get it so that we
can convert the lock to something useful, or we already had some higher level
lock and dropper to NL so another node can continue. This lock level does not
block any other nodes from access to the resource.

“PR” aka “Protected Read”. This is used to that multiple nodes might read the
resource at the same time without any mutual exclusion. This level blocks only
those nodes which want to make changes to the resource (EX locks).

“EX” aka “Exclusive”. This is used to keep other nodes from reading or changing
a resource while it is being changed by the current node. This level blocks PR
locks and other EX locks.

When another node wants a level of access to a resource which the current node
is blocking due to it’s lock level, that node “downconverts” the lock to a
compatible level. Sometimes we might have multiple nodes trying to gain
exclusive access to a resource at the same time (say two nodes want to go from
PR -> EX). When that happens, only one node can win and the others are sent
signals to ‘cancel’ their lock request and if need be, ‘downconvert’ to a mode
which is compatible with what’s being requested. In the previous example, that
means one of the nodes would cancel it’s attempt to go from PR->EX and
afterwards it would drop it’s PR to NL since the PR lock blocks the other node
from an EX.

After read the above text, I talked with Mark in IRC,  here is the edited (remove unnecessary part) conversation log,

coly: it’is an excellent material for DLM lock levels of ocfs2!
mark: specially if that helps folks understand what’s happening in dlmglue.c
* mark knows that code can be…. hard to follow 
mark: another thing you might want to take note of – this whole “cancel convert” business is there because the dlm allows a process to retain it’s current lock level while asking for an escalation
coly: one thing I am not clear is, what’s the functionality of dlmglue.c ? like the name, glue ?
mark: if you think about it – being forced to drop the lock and re-acquire would eliminate the possibility of deadlock, at the expense of performance
mark: think of dlmglue.c as the layer of code which abstracts away the dlm interface for the fs
mark: as part of that abstraction, file system lock management is wholly contained within dlmglue.c
coly: only dlmglue.c acts as a abstract layer ?  and the real job is done by fsdlm or o2dlm ?
mark: yes
mark: dlmglue is never actually creating resources itself – it’s asking the dlm on behalf of the file system
mark: aside from code cleanliness, dlmglue provides a number of features the fs needs that the dlm (rightfully) does not provide
coly: which kind of ?
mark: lock caching for example – you’ll notice that we keep counts on the locks in dlmglue
mark: also, whatever fs specific actions might be needed as part of a lock transition are initiated from dlmglue. an example of that would be checkpointing inode changes before allowing other nodes access, etc
coly: yeah, that’s one more thing confusing me.
coly:  It’s not clear to me yet, for the conception of upconvert and downconvert
coly: when it combined with ast and bast
coly: have you checked out the “dlmbook” pdf? it explains the dlm api (which once you understand, makes dlmglue a lot easier to figure out)
coly: yes, I read it. but because I didn’t know ast and bast before, I don’t have conception on what happens in ast and bast
coly: is it something like the signal handler ?
mark: ast and bast though are just callbacks we pass to the dlm. one (ast) is used to tell fs that a request is complete, the other (bast) is used to tell fs that a lock is blocking progress from another node
coly: when an ast is triggered, what will happen ? the node received the ast can make sure the requested lock level is granted ?
mark: generally yes. the procedure is: dlmglue fires off a request… some time later, the ast callback is run and the status it passes to dlmglue indicates whether the operation succeeded
coly: if a node receives a bast, what will happen ? I mean, are there options (e.g. release its lock, or ignore the bast) ?
mark: release the lock once possible
mark: that’s the only action that doesn’t lockup the cluster 
coly: I see, once a node receives a bast, it should try best to downconvert the coresponded lock to NL.
coly: it’s a little bit clear to me

I recite the log other than my own understanding, it can be helpful to get the basic conception of OCFS2′s dlm levels and what ast and bast do.

The air was so cold, I walked in the frozen wind for 1.5 hours.  It was fun to see the snow covered every where, especially the houses, cars, and plants. Several fat cats appeared on my way without glancing on me. I guesses they were looking for some warm place to stay, wish they felt comfortable last night and still be okey this morning. It’s probably that cats are stronger than me, after last night’s walk and even stayed in a warm room, I am afraid I’ve caught a chill

In China, it was a perfect sign for a big snow in beginning of year 2010.  Maybe this is another excited and impressive new year, if we are more diligent and optimistic, who knows ?

Junting Pan, an excellent Linux programmer in Beijing, a friend of mine, his daughter is dying. I am here asking more people to save the lovely life of a little girl.

Yifan, the 5 years old daughter of Pan, has a badly lung disease in past years, she almost died on Nov 11 2009 (http://help-yifan.org/img/notice.jpg).  In order to save her life, her parents must send their little girl to see some of the best specialists in the world, which means  a big amount of money ($300K~$500K US dollar).  This is an impossible number for a software engineer (especially in a developing country).

Yesterday, the last day of Year 2009, I visited Yifan’s family in Beijing. Her parents sold their only house to support the treatment expense, now the whole family stayed together in a small room.  Yifan’s mother and father were brave and strong-minded, we talked about Yifan’s physical situation and current donation amount. The great news was, by Dec 31, 2009, help-yifan.org got 314K RMB Yuan donation (most of it was from China mainland), which was almost 1/10 of the expected donation amount. Yifan said hello to me, and looked at me with sweet smile. She looked like a small flower, to wait for the beautiful sunshine of he life. What a great miracle if she can have a blissful tomorrow, while what a pity if she has to leave us due to the lung disease.

Last week, I got the remuneration of “Linkers and Loaders” Chinese translation, and donated it to little Yifan. I wish it’s helpful, but in order to save the life of Yifan, the family needs more help from more people in the world. If you read this blog, please do not hesitate to tell Yifan’s story to your friends.

If you want to help Yifan, please visit http://www.help-yifan.org (Chinese) or http://www.yifanfund.com (English)  , donation or volunteer are all helpful. Today is the first day of a brand new year. I wish Yifan to be able to have more new years in the future,  wish people from all of the world can help little Yifan, to make the life’s miracle happen.

Truncate Log

Truncate logs help to improve the delete performance. This system file allows the fs to collect freed bits and flush it to the global bitmap in chunks. What that also means is that space could be temporarily “lost” from the fs. As in, the space freed by deleting a large file may not show up immediately. One can view the orphan_dirs and the truncate_logs to account for such “lost” space.

To view a truncate log, do:

The truncate_log keeps records of start cluster# and number of clusters. The max number of such records “Total Records” depend on the block size. The above is for a 4K block size.

Since early this year, budget control happens in almost all companies/organizations, many local kernel developers in China could not attend LSF in United States (it’s quite interesting that most of kernel developers in China are storage related, mm, cgroup, io controller, fs, device mapper …). In such condition, we found there were enough people inside China to sit together for discussion on storage and file system related topics. In 2009 April, a proposal was posted on linux-kernel@zh-kernel.org for BeijingLSF. Many people provided positive feed back, then we started to organize this event.

A 7 persons’ committee was set up firstly, people were from Novell, Intel, Oracle, Redhat, Freescale. The committee made a 20 persons’ invitation list. The website was built on http://www.linuxevents.cn/beijinglsf and all invitees registered. Fortunately we got sponsorship from Novell China for soft drink and snack.

There were 6 sessions for BeijingLSF 2009. There was no talk, people just sat together to discuss on specific topics.

The first session was distributed locker manager. I led the session, the discussion included,

- introduced back ground of dlm, and current issues from fs/dlm (most of the issues were from my closed-or-opened and open-to-community BNCs).

- Oracle ocfs2 developers explained why ocfs2 using 64bytes lock value block.

- Jiaju Zhang (Novell) explained his patches for dlm performance improvement.

- Tao Ma (Oracle), Jiaju Zhang (Novell), Xinwei Hu (Novell) and I, discussed how dlm working with ocfs2′s user mode cluster stack.

The second session was clustering file system, led by Tao Ma (Oracle). Tao suggested people to introduce each other before the session. During the introduction, discussion happened when people introduced their current projects. When the discussion finished, 40 minutes passed. The workshop had no introduction time planed, therefore most time of this session was used for people to know each other. IMHO it was worth. This was the first time almost all storage and file system developers in China sat together, people came to know the faces behind email addresses.

The last session in the morning was shared storage and snapshot, led by Xinwei Hu (Novell). Xinwei introduced how logical volume management working in clustering environment, then discussion happened on,

- Considering snapshot start to happen on file system level, snapshot by device mapper might be less and less important in future.

- Is it possible to support snapshot by lvm in clustering environment and is it worth ? There was no conclusion from the discussion, and I’d like to hear from device mapper developers

After the lunch, the first session in the afternoon was VFS readahead and writeback. The session was led by Fengguang Wu (Intel), a 6 pages slide made people discuss for 90 minutes. Wu spent 20 minutes to introduce his patch, then people talked about,

- Why anonymous pages and file pages should be treated differently.

- In order to improvement writeback performance, MM should be able to suspend (maybe there is some better term) a process who making too many dirty pages.

- On some kind of SSD, linear read/write was slower than discrete read/write. If the storage media was SSD, there might be little difference for the writeback policy.

Second session in the afternoon was I/O controller and I/O bandwidth. The session was led by Jiangfeng Gui (Fujitsu). This talk was quite new to most of the attendees. Jianfeng explained the conception of io controller very well, at least I understood it was a software conception, not a haredware io controller was an interesting idea, but most of concern in the workshop was focused on its complexity.

The last session of the workshop was interaction with industry. We invited an engineer from Lenovo – Yilei Lu, who was working on a internet storage solution based on Linux operating system. Yilei introduced how they used Linux as base system in their storage solution, what problems or difficulties they encountered. Many people provided suggestions to the questions, and most of the developers were very happen to hear feed back from the development users.

After all the six sessions, there was light talks. Almost all attendees said this workshop was the first effort to make upstream active developers to sit together in China. Some people showed their willing to sponsor BeijingLSF next year (if there is), some people said they could help to organize similar events in their cities. IMHO, BeijingLSF is a great and successful event. The most important thing is even not discussion, this is the *first* time for *ALL* (yes ALL) most active storage related developers within China to see each other, and have chance to talk face to face. Unlike LSF in United States, BeijingLSF has little effect to Linux storage and file system development, anyway it’s a great effort to make discussion and face-to-face communication happen.

Novell acts a very important role and contributes quite a lot to BeijingLSF. I was able to use the ITO (what a great idea!) to help organize BeijingLSF, and Novell China sponsored soft drink and snack to make all attendees more comfortable while talking whole day.

Finally please permit me to thank all attendees, they are,

Bo Yang, Coly Li, Fengguang Wu, Herbert Xu, Jeff He, Jeff Liu, Jiaju Zhang, Jianfeng Gui, Michael Fu, Tao Ma, Tiger Yang, Xiao Luo, Xinwei Hu, Xu Wang, Yang Li, Yawei Niu, Yilei Lu, Yu Zhong, Zefan Li, Zheng Yan.

Your coming and participating make BeijingLSF being a great and successful event.

Beijing Linux Storage and File System Workshop 2009

[If you are interested on how the attendees look alike, please check http://picasaweb.google.com/colyli/BeijingLSF2009]

If anyone finds any mistake from the translation, please send the errata to publisher or to me directly. I do appreicate for your feed back

[NOTE: the cover picture is copied from china-pub.com ]

In September 16-20, I was in Nuremberg Germany for openSUSE Conference 2009.

In previous years, Labs member attended SuSE Labs conference. This year, the Labs conference was cancelled and we were encouraged to attend openSUSE Conference. IMHO, more investment on openSUSE community is a great idea, we need more hands from community.

I was invited to give a talk, the topic was about the open source development activities among a group of Chinese university students in Beijing. In the past 4 years, a group of university students in Beijing University of Post and Telecommunication contribute quite a few to open source community. In my talk, I introduced how the people were grouped and how the technical seminars were organized, of cause including the Google Summer of Code projects in the past 2 years. The slide file and video of my talk can be found on the internet [1].

OSC09 was a great chance to meet other community members, especially some ones did excellent contributions but never met before. For example, I spend 4~5 happy hours every month to read the openSUSE Weekly News. The News content is well organized and prepared, especially the community news and people of openSUSE. During the conference. One day I took Tram to conference venue from SUSE office, on the Tram I met a very nice guy, wore a black openSUSE T-shirt. We talked about the openSUSE community and the Weekly News, I was supprised to know him as a Weekly News editor after his self introduction, I never though I had opportunity to meet these cool guys face to face! This was the wonderful side effect of this conference, and collaboration happened. I decided to send text to him when I had valuable News, therefore I remembered his name — Sascha Manns.

This year I acted as mentor of a Google Summer of Code project, to guide a student to port openSUSE to MIPS platform (I will mention the project detail in another blog). During the conference, I met another Google Summer of Code group (Jan-Simon Möller, Martin Mohring, Adrian Schröter) who ported openSUSE to ARM platform. The openSUSE ARM porting student gave a talk on the conference, to introduce their job. I got very helpful information from his talk, and from the discussion after the talk. When we ported openSUSE to MIPS, we used system mode QEMU as the target MIPS hardware for RPM package building, which was every slow. Building GCC even spent around 5 days! The ARM porting team used a very smart method, they used user mode QEMU. The user mode QEMU is able to run a normal program on x86 machine which compiled for ARM processor, without emulating the whole system, compiling GCC just spends 3~4 hours. Right now QEMU does not support 64bit user mode, before integrating MIPS support to OBS (OpenSUSE Build Service), enabling the 64bit MIPS user mode support for QEMU might be our next target.

Since 2008, I know there is a community board of openSUSE (the board definitely exists earlier). On the second day here was a session to meet openSUSE board. Before the session, the board members were only symbols/strings/names to me. This time I knew they were 6 people (IIRC, why not 5 or 7 seats?) and who they were. The difficulty for me was, I could remember their faces, but was not able to pronounce their names correctly. In the Q&A time, I suggested to mark the pronunciation of board members on openSUSE website. This might not be a good idea, but really helpful for non native English (or other language) speakers to identify the community board members.

On the last day, there was an interesting session — ‘openSUSE Legal’. In this session, Jürgen Weigert and other people explained how to comp with software patent, different software release license. In the past years, I tried to assemble source code from MINIX (BSD like license), Linux Kernel (GPL2)), uClibc (GLGPL) into a hobby OS. I asked a question on how to do with this condition. The answer was quite clear, 1) If I could get announcement from the code authors to use a unified license, the unified license could be used. Otherwise 2) declare different license for different code. I need to find quite a lot time to declare different license to MLXOS [2].

Besides the above topics, I also attended some other very interesting sessions, e.g. Tackling a Buggy Kernel by Nikanth Karthikesan, Making Technology Previews Succeed by Suresh Jayaraman, openSUSE & Moblin by Michael Meeks, Visualizing Package Dependencies by Klaus Kampf, Git in the Build Service by Andreas Gruenbacher, Samba by Lars Müller … The final light talk was also impressive to me, especially the awesome Baconn

For openSUSE community, the OSC09 is a great event, we have chance to do face to face communication, which is very helpful to people work closer. Thanks to Novell for the conference sponsorship, wish all people continue to enjoy the community.

[1] Slide file and video of my talk:
http://blog.coly.li/docs/OSC09.coly.pdf
http://community.opensuse.org/conference/2009-09-18/Chinese_Students_Coly_Li_tape_IV_2009.09.18_12-11-31.dv
[2] MLXOS website:
http://www.mlxos.org
http://sourceforge.net/projects/mlxos/
[3] Conference schedule
http://en.opensuse.org/OpenSUSE_Conf_2009/Schedule
[4] Pictures of OSC09
http://lizards.opensuse.org/2009/09/19/opensuse-conference-photos/