Nov 20
UPDATE@2014-01-09:注意,在gdb attach成功以后,这个进程会被暂停,可能会导致一些问题。

UPDATE@2017-11-11:用 lsof | grep deleted ,可以看到被删除的问题文件,记住占用该文件的PID, 到 /proc//fd (该进程打开的所有文件,按fd的值命名)下面可以看到这个文件的另一个链接,把这个链接的内容清空,也可以解决。

场景:Linux下,进程 p 打开了文件 f 并在后台持续地往 f 中写入日志。某日发现磁盘空间不够,把 f 删掉了,这时 ls 已经看不到 f 的存在,但是 df 发现磁盘空间占用并未减小,而 lsof 仍然可以看到该文件被占用(并显示一个 "(deleted)" 后缀)。更不幸的是,进程 p 是需要长期驻留在后台运行的,不能直接干掉它。

解决:简单地说就是替进程解决这个文件。

1) 根据链接文件名,可以查到该文件在进程中的 fd :

    $ ls -l /proc/[PID]/fd

2) 通过 gdb 连上该进程(一般需要root权限)

    $ sudo gdb
    (gdb) attach [PID]

3) 清除该文件所占空间

    (gdb) call ftruncate(3, 0)    #这里假定fd = 3
    $1 = 0

这种方式治标,但不治本 —— 随着进程的继续运行,被删掉的 f 仍然会占用越来越多的空间;但是又不能残暴地直接 close(3) ,否则 p 的后续写入操作会出错,可能导致进程报错结束。

但是还是有办法的:

4) 移花接木

    (gdb) call dup(3)
    $2 = 4
    (gdb) call open("/dev/null", 2)    #注:2 = O_RDWR,x86/x86_64/arm上都是这个值。
    $3 = 5
    (gdb) call dup2(5, 3)
    $4 = 3
    (gdb) call close(4)
    $5 = 0

注:未测试该招式是否可能因多线程竞争导致错误。

OVER.
Nov 9

气球 不指定

felix021 @ 2012-11-9 16:25 [IT » 操作系统] 评论(0) , 引用(0) , 阅读(3202) | Via 本站原创
当主机内存想要回收一些虚拟机的内存时,应该怎么办?根据主机OS记录的内存使用情况来swap虚拟机占用的内存吗?不是的。

因为只有虚拟机的OS知道哪些内存是它最需要的,所以让它自己释放内存才是最好的选择。

怎么让它自己释放内存呢?对虚拟机比较了解的同学应该知道气球驱动(Balloon Driver)。其实原理很简单,就是在虚拟机里,使用一个进程申请并占用*一批内存,于是虚拟机的OS便会把它最不需要的内存释放掉一部分。然后这个进程再告诉主机OS我拿到这么多空间啦,你拿去用吧。

*注:申请内存和占用内存通常是两回事。实际上每次调用malloc(其实关键是brk系统调用)等函数分配内存时,系统只是在页表中标记,某些页已经分配给进程XXX,但是对应的地址空间并不是可用的。当进程使用到这个页的时候,会产生一个缺页中断,在中断例程中,系统才会真的从可用空间中分配一个页,然后再让进程继续使用。这个过程对于进程而言是透明的(不过可能会有一些延迟)。这种延迟机制在OS中大量使用,被实践证明是相当有效的,所以有拖延症的同学们,不要太担心哟,适当的拖延不见得是坏事

说了这么多废话,其实没到这篇的主题。

最近觉得公司配的台式机内存不够了(4G),由于我经常开大量的程序和网页,直到内存不够用的时候才关(拖延。。),因此常常是开个虚拟机的时候空闲内存立刻下降到0,这时候各种卡顿,连鼠标都卡。于是自费在X东上买了一条南亚易胜的 4GB DDR3 1600(这个牌子最便宜。。据说这个牌子给许多其他品牌代工)。安装上去以后,内存不够的现象显著缓解,一口气开三个虚拟机,腰不酸腿不痛的。

但是才用了两天,又发现空闲内存*不多了,经常是才剩下几百MB,有时竟然只有几十MB。虽然任务管理器里说了,8G内存中有6G+是“已缓存”,但是还是怀疑是不是某个进程占用了太多内存。于是一个一个截,全都截掉,空闲内存也还是不到2GB。

*注:Win7任务管理器中的”空闲内存“是malloc以来马上就可以给分配的。“已缓存”是操作系统用内存来保存硬盘上的数据(因为硬盘太慢了)。“可用内存”包括了空闲内存和已缓存。当进程申请的内存超过空闲内存的大小后,OS可以将已缓存的一部分释放掉,但是这个过程需要占用一段时间,效率不如直接使用空闲内存。

于是写了个气球程序来测试。最初的程序很简单,就是while(1)死循环,申请4M内存,然后memset清零。编译,运行,梆!出错了。看了下,进程只申请了2G的内存就出错了,简单分析就知道了,因为我用的是mingw32,生成的32位程序只能申请最多2G的用户空间,再一次malloc的时候,返回的是NULL,于是memset就会导致非法内存访问。

解决办法很简单…………跑3个,然后就申请并占用了6G内存,结束掉之后,发现任务管理器中的已缓存只剩一点点,空闲内存有了6G+,效果显著。看来的确是都被缓存了,不是某个进程太坑爹。注意:如果多跑了一个,就会发现第四个进程速度显著变慢,甚至拖累系统变得相当相当慢,说明这个时候已经在使用swap(或者叫交换空间,虚拟内存,pagefile,页面文件,分页文件……)了,所以不得不慢。

当然,更好的解决方法是编译生成一个64位的可执行程序,这样就能够申请足够多的空间了。到mingw64去下载一个rubenvb编译好的gcc套装直接编译,或者安装个visual studio,都行。

实际上,让系统放弃所有的缓存并不是好事。在XP以及更早的windows系统中,大概是开发人员假设用户的内存总是不够用的,所以系统不会大量使用内存来进行缓存。所以在内存大降价而vista/win7还没出来的时候(大概是08~09年),在XP机器上看到1~2G甚至更多内存并不奇怪,用不完怎么办呢?RAMDISK大行其道,虚拟一个分区出来,速度快得不行。XP的继任者Vista和Win7效仿Unix/Linux系的做法,尽量将内存用于缓存,在很多情况下都可以通过避免磁盘IO来提高系统的反应速度。

因此这里给出个最终版本,默认只回收2G的缓存,再怎么样,缓存3~4G的数据应该已经足够应付日常应用了。

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

const int block = 1024 * 1024 * 8; //8M

int main(int argc, char *argv[])
{
    int i = 0, reclaim = 2048;
    if (argc > 1)
        sscanf(argv[1], "%d", &reclaim);

    for (i = 0; i < reclaim; i += 8)
    {
        char *c = (char *)malloc(block);
        if (c == NULL)
            return 0;
        memset(c, 0, block);
        printf("%4d MB\n", i);
    }
    return 0;
}
Aug 8
这是第一个支持IBM PS/2和1.44MB 3.5寸软盘的DOS版本,可能是在家用PC上比较容易用虚拟机模拟的最古老的微软系操作系统。隐约记得这里头还有个BASICA解释器,比QBASIC还要老很多的那种,类似于文曲星上面的那个版本。
下载文件 (已下载 1061 次)

以前(大一之前)很喜欢玩这些东西,收集了不少东西,包括3.31, 6.22, win98/me/xp的DOS启动盘, windows 1.0 ~ 3.2(主要来自曾经的“bear5的软件地摊”),还有很多dos下的工具,tw ucdos 之类,甚至还有个VB DOS版。折腾bat、config.sys这些东西,玩得乐此不疲。如今突然想起,却发现它们静静地躺在硬盘的那个角落已经好多年了。

谨以此纪念那些二逼的时光。
Mar 23
以前一直纳闷,非特权用户不能编辑 /etc/rc.local ,应该如何实现开机启动任务的功能。。

刚刚详读了下 man 5 crontab ,才知道crontab的前五个参数除了可以用分时日月周之外,

还可以用一些预定义的类型(叫做Vixie cron),其中一个特殊的就是 @reboot :
引用
Instead of the first five fields, one of eight special strings may appear:

              string        meaning
              ------        -------
              @reboot        Run once, at startup.
              @yearly        Run once a year, "0 0 1 1 *".
              ......

也就是说,只要运行crontab -e,加入一行

@reboot /home/username/my_rc.local

就可以实现个人用户的 rc.local 啦!
Nov 23
按照某帖子里的说法,禁用掉WMPNetworkSvc(Windows Media Player Netwroking SharingService)即可正常使用sysprep部署了。

好久没发这么短的Blog了,简直就是微博了,OVER。
Nov 15
其实最早是想把XP装进移动硬盘,这样的话只要有需要随时可以从移动硬盘启动一个完整的系统。可惜无论是从安装程序安装还是Ghost,都会在XP滚动条过去以后就挂断(蓝屏或者直接重启)。发现有个USBOOT好像能够把XP放进去,但是还得注册帐号什么的,操作步骤也很麻烦。

最近各种折腾,最终结果是手头有个2个USB3.0的U盘。朗科 U903 8GB(某东现在特价69,很值得买):USB2.0下面读30M/s,写20M/s,USB3.0下读40M/s,写25M/s,延迟约1.1ms,也就是大约900IOPS;威刚S102 16GB(某东正常价139),USB2.0读写也是30/20左右,3.0还没实测,延时0.6ms,约1600IOPS。虽然连续读写速度和HDD没得比,但是IOPS却要快一个数量级,于是蛋疼地想着,是不是把Windows装上去试试,说不定还能体验一下SSD的快感。

PE SATA 1.9.6 里面有个WIM安装器,说是支持USB HDD,于是试着往U盘里面塞了个Win7进去,发现不行(估计非得是移动硬盘)。昨天在公司的时候查了一下,发现一个神器PWBoot 3.0.2可以patch Win7,昨晚S102被czyhd同学拿去拷了BF3,于是回家后只能用U903试了。

下载下来运行,发现PWBoot选择install.wim以后就出现数组越界错误,安装没法用。只有patch功能可以使,只好曲线救国。看到网上有人说VHD的事儿,才发现原来Win7已经原生支持VHD的创建、挂载、启动(启动啊!),out了好几年啊……

不废话了,昨晚折腾了很久,最后实现U盘启动的方式是这样的:

0. 打开compmgmt.msc,创建一个VHD,FixedSize或者Dynamic都可以。
1. 安装VirtualBox 4.x,这个支持VHD作为磁盘
2. 把VHD作为磁盘,安装Win7
3. 安装完以后打开cmdline,执行 c:\windows\system32\sysprep\sysprep.exe /generalize /oobe /shutdown
4. 等到VBox关机以后打开compmgmt.msc,右键磁盘管理->附加VHD,选择好挂载上。
5. 运行PWBoot,选择Patch Windows,把VHD上的Win7打个补丁
6. 将VHD的Win7分区Ghost到U盘(5G+)
7. 如果VHD有个100M的分区包含了boot目录和bootmgr,则一并拷贝到U盘的根目录下面
8. 启动,等待安装驱动(相当慢……………………)

第8步已经剧透了,效果很烂。

虽然30M的读取不快,但是不应该是瓶颈,初步估计是因为USB协议的原因,导致系统的运行受到限制,甚至刷新桌面都要卡呀卡的。

不过用VHD启动是个挺好玩的事儿,回头有空可以折腾折腾……
Nov 12

read/write乱翻 不指定

felix021 @ 2011-11-12 16:50 [IT » 操作系统] 评论(0) , 引用(0) , 阅读(3794) | Via 本站原创
最近和sandy一起在做的项目中,对文件系统有些纠结的地方。主要都是一致性问题。

比较简单的一个问题是,往某个文件末尾追加内容,希望保证断电数据不丢失,又想速度快。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);

因为fd2是dup出来的,所以跟fd1实际上指向的是同一个文件。如果fd2被关闭,那么fd1上的锁被释放。这一点比较好理解。但是后面跟着一个坑爹的情况:
fd1 = open(filename, ...);
read_lock(fd1, ...);
fd2 = open(filename, ...);
close(fd2);
注意:APUE说,这个情况和上一个情况是相同的。

大坑。

经过编码测试,的确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;
}

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,
    ........

也就是说,实际上调用的还是 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初体验 不指定

felix021 @ 2011-9-21 00:37 [IT » 操作系统] 评论(2) , 引用(0) , 阅读(9907) | Via 本站原创
昨天闲着蛋疼,白天把机器挂着下了个Win8开发者预览版,然后从公司远程到家里,UltraISO挂载,点击Setup,点了几个按钮,最后点了个Install,以为会让我选择安装在哪个分区然后再拷贝文件,没想到直接重启把Win7覆盖了,晚上回家一看,丫的已经安装好了,只差我创建帐号再点几个个人配置了。

进入系统以后发现不太习惯。默认进入的是Metro界面,按Windows键或者点击上面的Desktop区域返回桌面;传统的开始菜单貌似完全消失了,按Windows键只是在Metro和传统界面之间切换。Win7的应用都能安装(包括Chrome、QQ、迅雷、Flash插件),但是QQ的聊天窗口不能响应点击事件。此外就是不够稳定,会出现重启/注销卡死的情况,只能长按电源键。Metro界面提供了一些简单的APP,包括五子棋、Piano、Paint等等(其实Piano做的还不错)。可惜没有触摸设备,用鼠标点还是不太给力。

还好上周把Win7 Ghost了一份,截了图就换回Win7了,下面就贴些图吧:

点击在新窗口中浏览此图片
分页: 2/17 第一页 上页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]