2010年3月10日星期三

Forward

这个博客停止更新, 请到 www.thinksrc.com 查看最新的内容。

This blogger is stop update, please go www.thinksrc.com for updates.

2009年11月29日星期日

一个c语言小技巧,摘自minix fs

我说的小技巧就是最后的那句 err |= minix_sync_inode(inode);

真是懒的可以,Linus真是惜行如jing啊, 前面的错误检测和后面的都一并检查了,不过这里也有一个前提,就是 sync_mapping_buffers错误了,调用minix_sync_inode也不会导致更严重的问题。

学习学习。。。




int minix_sync_file(struct file * file,
struct dentry *dentry, int datasync)
{
struct inode *inode = dentry->d_inode;
int err;

err = sync_mapping_buffers(inode->i_mapping);
if (!(inode->i_state & I_DIRTY))
return err;
if (datasync && !(inode->i_state & I_DIRTY_DATASYNC))
return err;

err |= minix_sync_inode(inode);
return err ? -EIO : 0;
}

About File system logging

This is a note @MIT OCW 6.824 Lecture 7:

The main point of a log is make complex operations atomic.

I.e. operations that involve many individule writes. You want all writes or none, even if a crash in the middle.

A "transaction" is multi-write operation that should be atomic. The logging system needs to know which set of write from a transication.

Re-do with checkpoint:

Most logs work like this, e.g. FSD,
allows much faster recovery: ca use on-disk data
write-ahead rule:

delay flushing dirty block from in-memory data cache until corresponding commit recore is on disk

Check point rules:

all data writes before check point must be stable on disk checkpoint may not advance beyond first uncommitted Begin

Recovery:

for each block mentioned in the log
find the last xaction that wrote that block
if committed: re-do
if not committed: un-do

Why is logging fast:

group commit -- batched log writes.
could delay flushing log -- may lost committed transactions but at least you have a prefix.

Single seek to implement a transaction.
maybe less if no intervening disk activity, or group commit

Write-behind of data allows batched/schedules.
one data block may reflect many transactions, i.e. create many files in a directory.
don't have to be so careful since the log is the real infomation.

How can we avoid delete/create inconsistency?

This is a file system note: @MIT 6.824 2006 Lecture 6

Think this satiation,

unlink("f1");
create("f2");
Create happens to re-use the i-node freed by the unlink.
suppose only create write goes to disk, but none of the unlink's writes.

Crash.

After re-start, what does recovery see?

The file system looks correct! Nothing to fix!
But file f1 actually has file f2's contents!

Serious *undetected* inconsisency.

This is *not* a state the file system counld have been in if the crash had occured slightly earlier or later. And fsck did not notify the user there was an unfixable problem!

How can we avoid this delete/create inconsistency?

Observation: We only care about what's visible in the file system tree.

Goal: on-disk directory entry must always point to correct on-disk i-node.

Unlink Rule: remove dirent *on disk* before freeing i-node.

Create Rule: initialize new i-node *on disk* before creating directory entry.

In general, directory entry writes should be commit points.
Crash just before leves us with unused allocated i-node.
Crash just after is fine.

2009年11月15日星期日

感冒了,翻墙了

冬天气温降的很快,就连以往冬天不那么冷的广东,这次都很冷很冷了。我都感冒了, 不过不是猪流感。

还有一件事就是使用ssh tunnel翻墙了,很爽阿。

赞一个OpenSSH。

2009年10月29日星期四

real world FIND usage

from http://www.wagoneers.com/UNIX/FIND/find-usage.html


sudo find / -type f -name *.jpg -exec cp {} . \;

find . -type f -size +10000 -exec ls -al {} \;
find . -atime +1 -type f -exec mv {} TMP \; # mv files older then 1 day to dir TMP
find . -name "-F" -exec rm {} \; # a script error created a file called -F
find . -exec grep -i "vds admin" {} \;
find . \! -name "*.Z" -exec compress -f {} \;
find . -type f \! -name "*.Z" \! -name ".comment" -print | tee -a /tmp/list
find . -name *.ini
find . -exec chmod 775 {} \;
find . -user xuser1 -exec chown -R user2 {} \;
find . -name ebtcom*
find . -name mkbook
find . -exec grep PW0 {} \;
find . -exec grep -i "pw0" {} \;
find . -atime +6
find . -atime +6 -exec ll | more
find . -atime +6 -exec ll | more \;
find . -atime +6 -exec ll \;
find . -atime +6 -exec ls \;
find . -atime +30 -exec ls \;
find . -atime +30 -exec ls \; | wc -l
find . -name auth*
find . -exec grep -i plotme10 {};
find . -exec grep -i plotme10 {} \;
find . -ls -exec grep 'PLOT_FORMAT 22' {} \;
find . -print -exec grep 'PLOT_FORMAT 22' {} \;
find . -print -exec grep 'PLOT_FORMAT' {} \;
find . -print -exec grep 'PLOT_FORMAT' {} \;
find ./machbook -exec chown 184 {} \;
find . \! -name '*.Z' -exec compress {} \;
find . \! -name "*.Z" -exec compress -f {} \;
find /raid/03c/ecn -xdev -type f -print
find /raid/03c/ecn -xdev -path -type f -print
find / -name .ssh* -print | tee -a ssh-stuff
find . -name "*font*"
find . -name hpmcad*
find . -name *fnt*
find . -name hp_mcad* -print
find . -grep Pld {} \;
find . -exec grep Pld {} \;
find . -exec grep Pld {} \;
find . -exec grep PENWIDTH {} \; | more
find . -name config.pro
find . -name config.pro
find /raid -type d ".local_sd_customize" -print
find /raid -type d -name ".local_sd_customize" -print
find /raid -type d -name ".local_sd_customize" -ok cp /raid/04d/MCAD-apps/I_Custom/SD_custom/site_sd_customize/user_filer_project_dirs {} \;
find /raid -type d -name ".local_sd_customize" -exec cp /raid/04d/MCAD-apps/I_Custom/SD_custom/site_sd_customize/user_filer_project_dirs {} \;
find . -name xeroxrelease
find . -exec grep xeroxrelease {} \;
find . -name xeroxrelease
find . -name xeroxrelease* -print 2>/dev/null
find . -name "*release*" 2>/dev/null
find / -name "*xerox*" 2>/dev/null
find . -exec grep -i xeroxrelease {} \;
find . -print -exec grep -i xeroxrelease {} \;
find . -print -exec grep -i xeroxrelease {} \; > xeroxrel.lis
find . -exec grep -i xeroxrel {} \;
find . -print -exec grep -i xeroxrel {} \;
find . -print -exec grep -i xeroxrel {} \; | more
find /raid/03c/inwork -xdev -type f -print >> /raid/04d/user_scripts/prt_list.tmp
find . -exec grep '31.53' {} \;
find . -ls -exec grep "31/.53" {} \; > this.lis
find . -print -exec grep "31/.53" {} \; > this.lis
find . -print -exec grep 31.53 {} \; > this.lis
find . -exec grep -i pen {} /;
find . -exec grep -i pen {} \;
find . -print -exec grep -i pen {} \; | more
find . -exec grep -i pen {} \;
find . -atime +6 -exec ll | more \;
find . -atime +6 -exec ll \;
find . -atime +6 -exec ls \;
find . -atime +30 -exec ls \;
find . -atime +30 -exec ls \; | wc -l
find . \! -name '*.Z' -exec compress -f {} \;
find . -name 'cache*' -depth -exec rm {} \;
find . -name 'cache*' -depth -print | tee -a /tmp/cachefiles
find . -name 'cache[0-9][0-9]*' -depth -print | tee -a /tmp/cachefiles
find . -name 'hp_catfile' 'hp_catlock' -depth -print | tee -a /tmp/hp.cats
find . -name 'hp_catfile' -name 'hp_catlock' -depth -print | tee -a /tmp/hp.cats
find . -name 'hp_cat*' -depth -print | tee -a /tmp/hp.cats
find . -name 'hp_cat[fl]*' -depth -print | tee -a /tmp/hp.cats
find /raid -name 'hp_cat[fl]*' -depth -print
find . \! -name '*.Z' -exec compress -f {} \;
find . -name '*' -exec compress -f {} \;
find . -xdev -name "wshp1*" -print
find . -xdev -name "wagoneer*" -print
find . -name "xcmd" -depth -print
find /usr/contrib/src -name "xcmd" -depth -print
find /raid -type d -name ".local_sd_customize" -exec ls {} \;
find /raid -type d -name ".local_sd_customize" \
-exec cp /raid/04d/MCAD-apps/I_Custom/SD_custom/site_sd_customize/user_filer_project_dirs {} \;

2009年10月20日星期二

All about container_of

对一个这个宏的不理解导致了几个晚上的熬夜。写代码的时候一定不能迷糊阿!

这个是Linux kernel里面的宏, 作用大概如下, 现在你有一个


struct big{
struct small sname_in_big;
int some_else
};

struct small{}


然后有一个函数, 传入参数只有一个*small, 比如

void some_func(struct small *s);


在这个函数里面, 你想作这么一件事情, 想得到那个int some_else的值是多少, 而你的函数只有一个struct small* 的参数, 所以kernel里面就有这么一个函数可以帮你获得 struct big的指针。
就是container_of
在这个函数里面可以这样用:
 void some_func(struct small *s) {
struct big *b;
b = container_of (s, struct big, sname_in_big);
}

不过, 还有一个更重要的前提。 就是, 这个函数的参数的这个s,必须是struct big的一部分。 也就是说, 必须有这样一个步骤, struct big a; a.sname_in_big = some_small.
some_func(&a.sname_in_big);
才可以找到big的正确的地址。

这里的解释更详细:
http://www.kroah.com/log/linux/container_of.html