Nov
12
最近和sandy一起在做的项目中，对文件系统有些纠结的地方。主要都是一致性问题。
比较简单的一个问题是，往某个文件末尾追加内容，希望保证断电数据不丢失，又想速度快。fsycn可以保证缓存被刷到存储设备；但是在机械硬盘上执行fsync又变成了瓶颈。经过测试，在某机器上fsync大约每秒可以执行1100次左右。虽然目前能够满足业务需求，但是的确是项目中最大的瓶颈。解决办法就是花钱，买SSD。
还有几个麻烦的问题。
====
首先，记录锁。APUE 14.3 记录锁 中提到一个"锁的隐含和释放"
因为fd2是dup出来的，所以跟fd1实际上指向的是同一个文件。如果fd2被关闭，那么fd1上的锁被释放。这一点比较好理解。但是后面跟着一个坑爹的情况：
大坑。
经过编码测试，的确dup或者再次open的fd2（即使OPEN的时候用的是不同的flag）被关闭后，的确会出现记录锁的释放。一个进程中的另一个pthread线程（其他线程库没有测试过）关闭fd2效果是一致的（说明是用pid来识别锁的归属）。不过，如果使用flock(fd, LOCK_**)对整个文件进行加锁，则不会出现这个问题。
====
其次，write的原子性#1：进程a在调用write的期间，进程b是否可以往相同的文件中写数据？
《IEEE Std 1003.1, 2004 Edition》里面提到，当count<PIPE_BUF，如果write成功返回，write对pipe/FIFO的写入是原子的。但是对普通文件的写入呢？没有说明。
翻了一下 linux-2.6.38.8.tar.bz2 ，源码在 fs/read_write.c 中定义了 write 系统调用：
vfs_write调用的是 file->f_op->write , 如果这个指针是NULL，那么调用 do_sync_write。
以ext2为例，ext2/file.c 中定义了
也就是说，实际上调用的还是 do_sync_write 函数，蛋疼。更蛋疼的是，do_sync_write 在一个for循环里面(虽然是循环，但是没看出分段写入的意思） 调用的是 file->f_op->aio_write ，也就是上面的 generic_file_aio_write @ mm/filemap.c。这个函数获取了 file->f_mapping->inode, 然后对该inode加锁，调用 __generic_file_aio_write , 对inode解锁，然后根据文件的属性决定是否需要sync数据。（之所以有这么蛋疼的调用链，应该是不同的文件系统/内核其他功能模块在调用各个函数的时候，希望做一些包装，完成一些额外的事情）。
__generic_file_aio_write 大概有100行，kernel.org的<部分>说明是：
这个函数完成了将数据写入文件的所有必需操作。它要做的事情包括各种基本检查（可能被schedule）、删除文件的SUID、修改文件更新时间、调用更底层的操作（取决于是Direct IO还是Buffered Write）。
This function does all the work needed for actually writing data to a file. It does all basic checks, removes SUID from the file, updates modification times and calls proper subroutines depending on whether we do direct IO or a standard buffered write.
它期望 inode 的mutex已经被获取，除非是不需要锁的块设备或其它对象。（这个在generic_file_aio_write里面的确获取了）
It expects i_mutex to be grabbed unless we work on a block device or similar object which does not need locking at all.
从内核源码来看，只要 __generic_file_aio_write 没有返回，对同一个inode的写入是排斥的。但是写了个多线程的程序，每次对文件APPEND 1MB数据，各写1G。检查后发现并不是写入互斥的。（求kernel hacker解答……）
只是，每次原子写入的数据大小到底是多少？这个值会影响到很多应用的正确性，比如，日志文件的写入一般是追加的，如果一次追加的数据多于这个值，那么多个进程写同一个日志文件会很BUGGY。
====
再有，write的原子性#2：进程a在调用write的期间，进程b是否可以从相同的文件中读取数据？
读取的时候，一路从 read -> vfs_read -> do_sync_read -> generic_file_aio_read 没有需要获取 i_mutex 的地方。再到 do_generic_file_read 这个函数的时候，就是各种内存页面的处理，包括从页表找出实际的页，或者从磁盘中读取、换页之类（这个过程中可能被schedule）。当页面可用的时候，调用传入的 file_read_actor，这个函数使用硬件体系相关的 __copy_to_user(to, from, n) ...
看起来写操作和读操作并不是互斥的，这个也比较符合平时对文件操作的逻辑。不过从上一个问题可以看出的是，write并不是原子的，它是一段一段往内核BUFF里面写的，在每一段完成之前，read获取到的这一段数据还是旧数据。
====
最后，接上个问题，调用write写文件的时候，写入顺序是否是按地址顺序写入？如果不是的话，read可能先读到一段旧数据，再读到一段新数据，这个会让人崩溃的……
在这里，[写入]有两层意思：a. 写入缓存; b. 刷回存储设备。
对于写入缓存，实际上就是从用户空间将数据拷贝到内核空间，调用的是 __copy_from_user(to,from,n) 这个宏。这个宏的实现是在 arch 目录下，不同硬件平台的具体汇编代码。虽然没有去具体了解每个平台的实现方式（代价太大了，各种汇编啊……），但是几乎可以肯定，绝大部分平台下这个顺序是按照地址顺序写入的。虽然内核可以选择不顺序拷贝数据，但是开发者应该不会这么蛋疼吧……
对于刷回设备，调用的[应该](未考证，求证实)就是具体的fsync函数了，比如ext3下面是 fs/ext3/fsync.c 中的 ext3_sync_file 这个函数。这个由于跟具体设备相关，考证更困难了。。不过sandy同学举了个例子，磁带，就有可能是根据磁头目前的位置来刷写的，在有些时候逆向写效率更高（当然，同样未考证具体实现）。
应用程序调用read，实际上是从内核的缓存中获取数据的，所以一般的应用程序只需要关心 a. 写入缓存 的顺序就行了。从实现的合理性来判断，内核应该是按照顺序拷贝的。
我在stackoverflow.com问了最后这个问题，有人推荐了 http://flamingspork.com/talks/ 里面的 Eat My Data: How Everybody Gets File IO Wrong ，值得一看。
好吧。今天一整天就废在这上面了，本篇暂时到此为止，欢迎各种评论拍砖。
比较简单的一个问题是，往某个文件末尾追加内容，希望保证断电数据不丢失，又想速度快。fsycn可以保证缓存被刷到存储设备；但是在机械硬盘上执行fsync又变成了瓶颈。经过测试，在某机器上fsync大约每秒可以执行1100次左右。虽然目前能够满足业务需求，但是的确是项目中最大的瓶颈。解决办法就是花钱，买SSD。
还有几个麻烦的问题。
====
首先，记录锁。APUE 14.3 记录锁 中提到一个"锁的隐含和释放"
fd1 = open(filename, ...);
read_lock(fd1, ...); //这个是APUE自带的apue.h中定义的一个宏，调用fcntl(fd, F_SETLK, ...)
fd2 = dup(fd1);
close(fd2);
read_lock(fd1, ...); //这个是APUE自带的apue.h中定义的一个宏，调用fcntl(fd, F_SETLK, ...)
fd2 = dup(fd1);
close(fd2);
因为fd2是dup出来的，所以跟fd1实际上指向的是同一个文件。如果fd2被关闭，那么fd1上的锁被释放。这一点比较好理解。但是后面跟着一个坑爹的情况：
fd1 = open(filename, ...);
read_lock(fd1, ...);
fd2 = open(filename, ...);
close(fd2);
注意：APUE说，这个情况和上一个情况是相同的。read_lock(fd1, ...);
fd2 = open(filename, ...);
close(fd2);
大坑。
经过编码测试，的确dup或者再次open的fd2（即使OPEN的时候用的是不同的flag）被关闭后，的确会出现记录锁的释放。一个进程中的另一个pthread线程（其他线程库没有测试过）关闭fd2效果是一致的（说明是用pid来识别锁的归属）。不过，如果使用flock(fd, LOCK_**)对整个文件进行加锁，则不会出现这个问题。
====
其次，write的原子性#1：进程a在调用write的期间，进程b是否可以往相同的文件中写数据？
《IEEE Std 1003.1, 2004 Edition》里面提到，当count<PIPE_BUF，如果write成功返回，write对pipe/FIFO的写入是原子的。但是对普通文件的写入呢？没有说明。
翻了一下 linux-2.6.38.8.tar.bz2 ，源码在 fs/read_write.c 中定义了 write 系统调用：
SYSCALL_DEFINE3(write, unsigned int, fd, const char __user *, buf,
size_t, count)
{
struct file *file;
ssize_t ret = -EBADF;
int fput_needed;
file = fget_light(fd, &fput_needed); //根据fd获取struct file；如果refcnt>0，加锁
if (file) {
loff_t pos = file_pos_read(file); //获取文件当前位置
ret = vfs_write(file, buf, count, &pos); //调用vfs层进行写入
file_pos_write(file, pos); //更新文件位置
fput_light(file, fput_needed); //如果fget_light加锁了，解锁
}
return ret;
}
size_t, count)
{
struct file *file;
ssize_t ret = -EBADF;
int fput_needed;
file = fget_light(fd, &fput_needed); //根据fd获取struct file；如果refcnt>0，加锁
if (file) {
loff_t pos = file_pos_read(file); //获取文件当前位置
ret = vfs_write(file, buf, count, &pos); //调用vfs层进行写入
file_pos_write(file, pos); //更新文件位置
fput_light(file, fput_needed); //如果fget_light加锁了，解锁
}
return ret;
}
vfs_write调用的是 file->f_op->write , 如果这个指针是NULL，那么调用 do_sync_write。
以ext2为例，ext2/file.c 中定义了
const struct file_operations ext2_file_operations = {
.llseek = generic_file_llseek,
.read = do_sync_read,
.write = do_sync_write,
.aio_read = generic_file_aio_read,
.aio_write = generic_file_aio_write,
........
.llseek = generic_file_llseek,
.read = do_sync_read,
.write = do_sync_write,
.aio_read = generic_file_aio_read,
.aio_write = generic_file_aio_write,
........
也就是说，实际上调用的还是 do_sync_write 函数，蛋疼。更蛋疼的是，do_sync_write 在一个for循环里面(虽然是循环，但是没看出分段写入的意思） 调用的是 file->f_op->aio_write ，也就是上面的 generic_file_aio_write @ mm/filemap.c。这个函数获取了 file->f_mapping->inode, 然后对该inode加锁，调用 __generic_file_aio_write , 对inode解锁，然后根据文件的属性决定是否需要sync数据。（之所以有这么蛋疼的调用链，应该是不同的文件系统/内核其他功能模块在调用各个函数的时候，希望做一些包装，完成一些额外的事情）。
__generic_file_aio_write 大概有100行，kernel.org的<部分>说明是：
这个函数完成了将数据写入文件的所有必需操作。它要做的事情包括各种基本检查（可能被schedule）、删除文件的SUID、修改文件更新时间、调用更底层的操作（取决于是Direct IO还是Buffered Write）。
This function does all the work needed for actually writing data to a file. It does all basic checks, removes SUID from the file, updates modification times and calls proper subroutines depending on whether we do direct IO or a standard buffered write.
它期望 inode 的mutex已经被获取，除非是不需要锁的块设备或其它对象。（这个在generic_file_aio_write里面的确获取了）
It expects i_mutex to be grabbed unless we work on a block device or similar object which does not need locking at all.
从内核源码来看，只要 __generic_file_aio_write 没有返回，对同一个inode的写入是排斥的。但是写了个多线程的程序，每次对文件APPEND 1MB数据，各写1G。检查后发现并不是写入互斥的。（求kernel hacker解答……）
只是，每次原子写入的数据大小到底是多少？这个值会影响到很多应用的正确性，比如，日志文件的写入一般是追加的，如果一次追加的数据多于这个值，那么多个进程写同一个日志文件会很BUGGY。
====
再有，write的原子性#2：进程a在调用write的期间，进程b是否可以从相同的文件中读取数据？
读取的时候，一路从 read -> vfs_read -> do_sync_read -> generic_file_aio_read 没有需要获取 i_mutex 的地方。再到 do_generic_file_read 这个函数的时候，就是各种内存页面的处理，包括从页表找出实际的页，或者从磁盘中读取、换页之类（这个过程中可能被schedule）。当页面可用的时候，调用传入的 file_read_actor，这个函数使用硬件体系相关的 __copy_to_user(to, from, n) ...
看起来写操作和读操作并不是互斥的，这个也比较符合平时对文件操作的逻辑。不过从上一个问题可以看出的是，write并不是原子的，它是一段一段往内核BUFF里面写的，在每一段完成之前，read获取到的这一段数据还是旧数据。
====
最后，接上个问题，调用write写文件的时候，写入顺序是否是按地址顺序写入？如果不是的话，read可能先读到一段旧数据，再读到一段新数据，这个会让人崩溃的……
在这里，[写入]有两层意思：a. 写入缓存; b. 刷回存储设备。
对于写入缓存，实际上就是从用户空间将数据拷贝到内核空间，调用的是 __copy_from_user(to,from,n) 这个宏。这个宏的实现是在 arch 目录下，不同硬件平台的具体汇编代码。虽然没有去具体了解每个平台的实现方式（代价太大了，各种汇编啊……），但是几乎可以肯定，绝大部分平台下这个顺序是按照地址顺序写入的。虽然内核可以选择不顺序拷贝数据，但是开发者应该不会这么蛋疼吧……
对于刷回设备，调用的[应该](未考证，求证实)就是具体的fsync函数了，比如ext3下面是 fs/ext3/fsync.c 中的 ext3_sync_file 这个函数。这个由于跟具体设备相关，考证更困难了。。不过sandy同学举了个例子，磁带，就有可能是根据磁头目前的位置来刷写的，在有些时候逆向写效率更高（当然，同样未考证具体实现）。
应用程序调用read，实际上是从内核的缓存中获取数据的，所以一般的应用程序只需要关心 a. 写入缓存 的顺序就行了。从实现的合理性来判断，内核应该是按照顺序拷贝的。
我在stackoverflow.com问了最后这个问题，有人推荐了 http://flamingspork.com/talks/ 里面的 Eat My Data: How Everybody Gets File IO Wrong ，值得一看。
好吧。今天一整天就废在这上面了，本篇暂时到此为止，欢迎各种评论拍砖。
Sep
21
昨天闲着蛋疼，白天把机器挂着下了个Win8开发者预览版，然后从公司远程到家里，UltraISO挂载，点击Setup，点了几个按钮，最后点了个Install，以为会让我选择安装在哪个分区然后再拷贝文件，没想到直接重启把Win7覆盖了，晚上回家一看，丫的已经安装好了，只差我创建帐号再点几个个人配置了。
进入系统以后发现不太习惯。默认进入的是Metro界面，按Windows键或者点击上面的Desktop区域返回桌面；传统的开始菜单貌似完全消失了，按Windows键只是在Metro和传统界面之间切换。Win7的应用都能安装（包括Chrome、QQ、迅雷、Flash插件），但是QQ的聊天窗口不能响应点击事件。此外就是不够稳定，会出现重启/注销卡死的情况，只能长按电源键。Metro界面提供了一些简单的APP，包括五子棋、Piano、Paint等等（其实Piano做的还不错）。可惜没有触摸设备，用鼠标点还是不太给力。
还好上周把Win7 Ghost了一份，截了图就换回Win7了，下面就贴些图吧：
进入系统以后发现不太习惯。默认进入的是Metro界面，按Windows键或者点击上面的Desktop区域返回桌面；传统的开始菜单貌似完全消失了，按Windows键只是在Metro和传统界面之间切换。Win7的应用都能安装（包括Chrome、QQ、迅雷、Flash插件），但是QQ的聊天窗口不能响应点击事件。此外就是不够稳定，会出现重启/注销卡死的情况，只能长按电源键。Metro界面提供了一些简单的APP，包括五子棋、Piano、Paint等等（其实Piano做的还不错）。可惜没有触摸设备，用鼠标点还是不太给力。
还好上周把Win7 Ghost了一份，截了图就换回Win7了，下面就贴些图吧：
Jun
15
我喜欢在自己的 $HOME 下面建立一个 bin ，然后添加到 $PATH 中，这样我可以方便地执行自己的程序：
$ mkdir ~/bin
$ vi .bashrc
export PATH=$PATH:~/bin
不过坑爹的 crontab 对 .bashrc 并不买账，通过
* * * * * echo $PATH > ~/cronpath.txt
可以看出， crontab 执行命令时没有把环境变量给切过来。
$ cat ~/cronpath.txt
/usr/bin:/bin
$ mkdir ~/bin
$ vi .bashrc
export PATH=$PATH:~/bin
不过坑爹的 crontab 对 .bashrc 并不买账，通过
* * * * * echo $PATH > ~/cronpath.txt
可以看出， crontab 执行命令时没有把环境变量给切过来。
$ cat ~/cronpath.txt
/usr/bin:/bin
Jun
14
#UPDATE: 并不是不能处理反引号，而是不能直接写%，需要转义。
某脚本x.sh，接受一个参数，比如20110517，用于处理20110517的日志。
处理前一天的日志，非常理所当然地使用如下命令
由于是每天早上8点30分执行，所以很理所当然地：
$ crontab -e
30 8 * * * PATH_TO_SCRIPT/x.sh `date -d "-1 day" +%Y%m%d`
但是过了几天发现脚本根本就没有被处理（在某些机器上，cron fail时会将邮件发送给用户"You have new mail in /var/spool/mail/USERNAME"）。
原因是坑爹的cron没法正确处理反引号。
解决办法是，额外写个脚本将这句命令包装，在crontab中执行包装脚本 在%前面都加上反斜杠。
某脚本x.sh，接受一个参数，比如20110517，用于处理20110517的日志。
处理前一天的日志，非常理所当然地使用如下命令
PATH_TO_SCRIPT/x.sh `date -d "-1 day" +%Y%m%d`
由于是每天早上8点30分执行，所以很理所当然地：
$ crontab -e
30 8 * * * PATH_TO_SCRIPT/x.sh `date -d "-1 day" +%Y%m%d`
但是过了几天发现脚本根本就没有被处理（在某些机器上，cron fail时会将邮件发送给用户"You have new mail in /var/spool/mail/USERNAME"）。
解决办法是，
Dec
2
Ubuntu Server 10.04 x86和x86_64下是8MB，RHEL4 x86下是10MB。开线程的开销真大。
#include <pthread.h>
#include <stdio.h>
void *thread(void *arg)
{
size_t stacksize;
pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_attr_getstacksize (&attr, &stacksize);
printf("Default stack size = %lu KB\n", stacksize / 1024);
}
int main(int argc, char *argv[])
{
void *x;
pthread_t t;
pthread_create(&t, NULL, thread, NULL);
pthread_join(t, &x);
return 0;
}
#include <stdio.h>
void *thread(void *arg)
{
size_t stacksize;
pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_attr_getstacksize (&attr, &stacksize);
printf("Default stack size = %lu KB\n", stacksize / 1024);
}
int main(int argc, char *argv[])
{
void *x;
pthread_t t;
pthread_create(&t, NULL, thread, NULL);
pthread_join(t, &x);
return 0;
}
Nov
2
上一篇谈到：“典型的情况是某些非法内存访问，Glibc会open("/dev/tty",...)，write()一些错误信息，然后open("/proc/self/maps", ...)把进程的内存映射表输出。还有一个更常见的情况，那就是用qsort。GCC的qsort实现，会主动open(/proc/meminfo)，获取一些信息，通过这些信息来最优化排序时的内存管理。” 通过执行
对于这类情况，ptrace监控进程open系统调用，并获取文件名，检查文件名是否合法，如果合法，予以放行，这样就可以避免上述RE被误判为RF的情况了。
说起来很简单，但是具体做起来就有点麻烦。不过可以从我写woj-land的时候参考的ptrace教程《Playing with ptrace, 玩转ptrace》入手。这篇非常不错，强烈推荐有兴趣的同学学习学习：
Playing with ptrace, Part I — 玩转ptrace(一) http://www.kgdb.info/gdb/playing_with_ptrace_part_i/
Playing with ptrace, Part II — 玩转ptrace(二) http://www.kgdb.info/gdb/playing_with_ptrace_part_ii/
上篇以write系统调用为例，介绍了write系统调用的等价汇编码（当然是早期的了，现在的pc上linux貌似不用0x80了）、截获write系统调用，获取write系统调用的参数和返回值、甚至反转write系统调用的输出。具体的看原文了。
在这里，我需要peek的是read系统调用的参数。以x86为例，一个最简单的read系统调用：
注意：虽然ebx中存放的是地址，但是不是用户程序可以直接读取的，需要通过ptrace的PTRACE_PEEKDATA命令来获取。该命令一次可以获取sizeof(long)个字节的内容，如果要获取字符串的所有内容，就得通过循环来完成。
此外，为了保证代码能够在x86_64架构下通过编译，需要把上述代码做个小修改：
通过这种方式，能够识别出open系统调用打开的文件，在保证系统安全的情况下，改善了Judge的识别能力。
更具体的代码可以参见：
http://code.google.com/p/woj-land/source/browse/trunk/code/judge/judge.h?spec=svn150&r=150#671
strace ./a.out 2>&1 | grep open
可以看到进程执行的open系统调用。对于这类情况，ptrace监控进程open系统调用，并获取文件名，检查文件名是否合法，如果合法，予以放行，这样就可以避免上述RE被误判为RF的情况了。
说起来很简单，但是具体做起来就有点麻烦。不过可以从我写woj-land的时候参考的ptrace教程《Playing with ptrace, 玩转ptrace》入手。这篇非常不错，强烈推荐有兴趣的同学学习学习：
Playing with ptrace, Part I — 玩转ptrace(一) http://www.kgdb.info/gdb/playing_with_ptrace_part_i/
Playing with ptrace, Part II — 玩转ptrace(二) http://www.kgdb.info/gdb/playing_with_ptrace_part_ii/
上篇以write系统调用为例，介绍了write系统调用的等价汇编码（当然是早期的了，现在的pc上linux貌似不用0x80了）、截获write系统调用，获取write系统调用的参数和返回值、甚至反转write系统调用的输出。具体的看原文了。
在这里，我需要peek的是read系统调用的参数。以x86为例，一个最简单的read系统调用：
read("/proc/meminfo", O_RDONLY)
，大致等同于movl $5, %eax ;open的系统调用编号
movl $filename, %ebx ;文件名地址(这里不一定对)
movl $0, %ecx ;open的flags: O_RDONLY
int $0x80
也就是说，可以通过获取x86 CPU寄存器的值来取得系统调用的参数，具体代码如下：movl $filename, %ebx ;文件名地址(这里不一定对)
movl $0, %ecx ;open的flags: O_RDONLY
int $0x80
user_regs_struct regs;
ptrace(PTRACE_GETREGS, child, NULL, ®s);
syscall_id = regs.orig_eax; //因为eax也是用来填写函数返回值的，所以该struct额外增加了一个orig_eax
params[0] = regs.ebx;
params[1] = regs.ecx;
union u{ unsigned long val; char chars[sizeof(long)]; }data;
data.val = ptrace(PTRACE_PEEKDATA, child, params[0], NULL);
ptrace(PTRACE_GETREGS, child, NULL, ®s);
syscall_id = regs.orig_eax; //因为eax也是用来填写函数返回值的，所以该struct额外增加了一个orig_eax
params[0] = regs.ebx;
params[1] = regs.ecx;
union u{ unsigned long val; char chars[sizeof(long)]; }data;
data.val = ptrace(PTRACE_PEEKDATA, child, params[0], NULL);
注意：虽然ebx中存放的是地址，但是不是用户程序可以直接读取的，需要通过ptrace的PTRACE_PEEKDATA命令来获取。该命令一次可以获取sizeof(long)个字节的内容，如果要获取字符串的所有内容，就得通过循环来完成。
此外，为了保证代码能够在x86_64架构下通过编译，需要把上述代码做个小修改：
#if __WORDSIZE == 32
syscall_id = regs.orig_eax;
params[0] = regs.ebx;
params[1] = regs.ecx;
#else
syscall_id = regs.orig_rax;
params[0] = regs.rdi;
params[1] = regs.rsi;
#endif
syscall_id = regs.orig_eax;
params[0] = regs.ebx;
params[1] = regs.ecx;
#else
syscall_id = regs.orig_rax;
params[0] = regs.rdi;
params[1] = regs.rsi;
#endif
通过这种方式，能够识别出open系统调用打开的文件，在保证系统安全的情况下，改善了Judge的识别能力。
更具体的代码可以参见：
http://code.google.com/p/woj-land/source/browse/trunk/code/judge/judge.h?spec=svn150&r=150#671
Aug
26
上一次的方法虽然达到了基本要求，但是还是有很多不爽的地方，尤其是
1. 当需要直接操作该虚拟机，或者修改运行时参数（比如增加共享文件夹、修改网卡的模式、分配光驱）时，需要将虚拟机关闭或者休眠，然后再重新用vbox打开，很麻烦，更重要的是当前ssh会话环境全都要关闭，再次建立很麻烦。
2. 由于虚拟机是后台运行的，在关机的时候可能会被忽略，影响数据的安全性，甚至会导致虚拟机挂掉——我遇到的情况是apt包管理器的缓存文件出错，无法安装或卸载现有程序。于是干脆重装了下（把alternate版换成了server版）。
于是上网搜了一下，找到一款很不错的绿色软件——RBTray，可以强制将软件放入托盘(Systray)中，隐藏它在任务栏占用的位置。
这款软件可以在这里下载：http://rbtray.sourceforge.net/
把它下载，解压，运行，然后右键单击窗口的最小化图标，绝大部分窗口就会最小化到托盘中去。
然后在桌面上额外创建两个bat文件：
start.bat
stop.bat
完美:D
1. 当需要直接操作该虚拟机，或者修改运行时参数（比如增加共享文件夹、修改网卡的模式、分配光驱）时，需要将虚拟机关闭或者休眠，然后再重新用vbox打开，很麻烦，更重要的是当前ssh会话环境全都要关闭，再次建立很麻烦。
2. 由于虚拟机是后台运行的，在关机的时候可能会被忽略，影响数据的安全性，甚至会导致虚拟机挂掉——我遇到的情况是apt包管理器的缓存文件出错，无法安装或卸载现有程序。于是干脆重装了下（把alternate版换成了server版）。
于是上网搜了一下，找到一款很不错的绿色软件——RBTray，可以强制将软件放入托盘(Systray)中，隐藏它在任务栏占用的位置。
这款软件可以在这里下载：http://rbtray.sourceforge.net/
把它下载，解压，运行，然后右键单击窗口的最小化图标，绝大部分窗口就会最小化到托盘中去。
然后在桌面上额外创建两个bat文件：
start.bat
VBOX安装路径\VBoxManage startvm Ubuntu
stop.bat
VBOX安装路径\VBoxManage controlvm Ubuntu savestate
完美:D
Aug
22
一个简单的程序：
编译运行：
搞怪：
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/types.h>
int main(int argc, char *argv[])
{
int fd = open(argv[1], O_CREAT | O_WRONLY);
if (fd < 0)
{
printf("err open");
return 1;
}
u_int64_t sz = lseek64(fd, (1ull << 40) - 1, SEEK_SET);
if (sz < 0)
{
printf("err lseek64");
return 2;
}
int nWrite = write(fd, &fd, 1);
printf("nWrite = %d\n", nWrite);
close(fd);
return 0;
}
#include <unistd.h>
#include <fcntl.h>
#include <sys/types.h>
int main(int argc, char *argv[])
{
int fd = open(argv[1], O_CREAT | O_WRONLY);
if (fd < 0)
{
printf("err open");
return 1;
}
u_int64_t sz = lseek64(fd, (1ull << 40) - 1, SEEK_SET);
if (sz < 0)
{
printf("err lseek64");
return 2;
}
int nWrite = write(fd, &fd, 1);
printf("nWrite = %d\n", nWrite);
close(fd);
return 0;
}
编译运行：
引用
$ gcc -o hole hole.c -D_FILE_OFFSET_BITS=64
$ ./hole disk
$ ls -lh disk
-rwxr-S--- 1 felix021 felix021 1.0T 2010-08-20 14:36 disk
$ ./hole disk
$ ls -lh disk
-rwxr-S--- 1 felix021 felix021 1.0T 2010-08-20 14:36 disk
搞怪：
引用
felix021@ubuntu-vbox:~/code$ mkdir mnt
felix021@ubuntu-vbox:~/code$ sudo mkfs.vfat disk
mkfs.vfat 3.0.7 (24 Dec 2009)
felix021@ubuntu-vbox:~/code$ sudo mount -oloop disk mnt
felix021@ubuntu-vbox:~/code$ df -lh
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 5.2G 1.5G 3.5G 30% /
...
/dev/sda1 2.3G 957M 1.3G 43% /home
/dev/loop0 1.0T 16K 1.0T 1% /home/felix021/code/mnt
felix021@ubuntu-vbox:~/code$ sudo mkfs.vfat disk
mkfs.vfat 3.0.7 (24 Dec 2009)
felix021@ubuntu-vbox:~/code$ sudo mount -oloop disk mnt
felix021@ubuntu-vbox:~/code$ df -lh
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 5.2G 1.5G 3.5G 30% /
...
/dev/sda1 2.3G 957M 1.3G 43% /home
/dev/loop0 1.0T 16K 1.0T 1% /home/felix021/code/mnt
