最新 | 最热门 | 最高评价

+0  Docker基础技术:DeviceMapper

Tag: Unix/Linux | 操作系统 | 杂项资源 | Device Mapper | Docker | Linux | Thin Provisioning
陈皓 发于 2015年08月26日 08:21 | 点击: 930 | 展开摘要
在上一篇介绍AUFS的文章中,大家可以看到,Docker的分层镜像是怎么通过UnionFS这种文件系统做到的,但是,因为Docker首选的AUFS并不在Linux的内核主干里,所以,对于非Ubuntu的Linux分发包,比如CentOS,就无法使用AUFS作为Docker的文件系统了。于是作为第二优先级的DeviceMapper就被拿出来做分层镜像的一个实现。

Device Mapper 简介

DeviceMapper自Linux 2.6被引入成为了Linux最重要的一个

查看全文: http://www.udpwork.com/item/14547.html

+0  Docker基础技术:AUFS

Tag: Unix/Linux | 操作系统 | 杂项资源 | AUFS | Docker | Linux | UnionFS
陈皓 发于 2015年08月24日 08:01 | 点击: 779 | 展开摘要
AUFS是一种Union File System,所谓UnionFS就是把不同物理位置的目录合并mount到同一个目录中。UnionFS的一个最主要的应用是,把一张CD/DVD和一个硬盘目录给联合 mount在一起,然后,你就可以对这个只读的CD/DVD上的文件进行修改(当然,修改的文件存于硬盘上的目录里)。

AUFS又叫Another UnionFS,后来叫Alternative UnionFS,后来可能觉得不够霸气,叫成Advance UnionFS。是个叫Junjir

查看全文: http://www.udpwork.com/item/14535.html

+0  Docker基础技术:Linux CGroup

Tag: Unix/Linux | 操作系统 | 杂项资源 | cgroup | Docker | Linux
陈皓 发于 2015年04月17日 09:03 | 点击: 943 | 展开摘要
前面,我们介绍了Linux Namespace,但是Namespace解决的问题主要是环境隔离的问题,这只是虚拟化中最最基础的一步,我们还需要解决对计算机资源使用上的隔离。也就是说,虽然你通过Namespace把我Jail到一个特定的环境中去了,但是我在其中的进程使用用CPU、内存、磁盘等这些计算资源其实还是可以随心所欲的。所以,我们希望对进程进行资源利用上的限制或控制。这就是Linux CGroup出来了的原因。

Linux CGroup全称Linux Control G

查看全文: http://www.udpwork.com/item/14098.html

+0  Docker基础技术:Linux Namespace(下)

Tag: Unix/Linux | 操作系统 | Docker | Linux | Namespace
陈皓 发于 2015年04月16日 10:19 | 点击: 698 | 展开摘要
在 Docker基础技术:Linux Namespace(上篇)中我们了解了,UTD、IPC、PID、Mount 四个namespace,我们模仿Docker做了一个相当相当山寨的镜像。在这一篇中,主要想向大家介绍Linux的User和Network的Namespace。

好,下面我们就介绍一下还剩下的这两个Namespace。

User Namespace

User Namespace主要是用了CLONE_NEWUSER的参数。使用了这个参数后,内部看到的UID和GI

查看全文: http://www.udpwork.com/item/14100.html

+0  小米的两个大词

Tag: TMT乱弹 | 媒体供稿 | 小米 | 操作系统 | 生态 | 腾讯科技
魏武挥 发于 2015年04月09日 11:33 | 点击: 808 | 展开摘要


小米近来的新品推出速度很快。

手机、平板、电视机,那是当今所谓智能设备的老三样。

其它品类简直让人眼花缭乱,手环是个老东西了,后来又弄了电源、路由器、空气净化器、摄像机等,最新的东西是插线板。

小米以苹果为师,雷军甚至有“雷布斯”的称号,但在品类扩充上,小米显然比它的师傅更激进些,更重要的差别是,价格路线从来不走苹果般的高端,基本上以“价廉物美”取胜。比如说,让小米成为中国手机出货量的一线品牌,低价的红米,立下了汗马功劳。

小米用投资的方式来推动新品的扩张,比如

查看全文: http://www.udpwork.com/item/14075.html

+0  vfork 挂掉的一个问题

Tag: C/C++语言 | Unix/Linux | 操作系统 | fork | Linux | Unix | vfork
陈皓 发于 2014年11月21日 00:48 | 点击: 1063 | 展开摘要
在知乎上,有个人问了这样的一个问题——为什么vfork的子进程里用return,整个程序会挂掉,而且exit()不会?并给出了如下的代码,下面的代码一运行就挂掉了,但如果把子进程的return改成exit(0)就没事。

我受邀后本来不想回答这个问题的,因为这个问题明显就是RTFM的事,后来,发现这个问题放在那里好长时间,而挂在下面的几个答案又跑偏得比较严重,我觉得可能有些朋友看到那样的答案会被误导,所以就上去回答了一下这个问题。

下面我把问题和我的回答发布在这里,也供更多

查看全文: http://www.udpwork.com/item/13542.html

+0  bash代码注入的安全漏洞

Tag: Unix/Linux | 技术新闻 | 操作系统 | 网络安全 | Bash | env | export | 安全 | 安全补丁 | 环境变量
陈皓 发于 2014年09月28日 07:56 | 点击: 1111 | 展开摘要
很多人或许对上半年发生的安全问题“心脏流血”(Heartbleed Bug)事件记忆颇深,这两天,又出现了另外一个“毁灭级”的漏洞——Bash软件安全漏洞。这个漏洞由法国GNU/Linux爱好者Stéphane Chazelas所发现。随后,美国电脑紧急应变中心(US-CERT)、红帽以及多家从事安全的公司于周三(北京时间9月24日)发出警告。 关于这个安全漏洞的细节可参看美国政府计算安全的这两个漏洞披露:CVE-2014-6271 和 CVE-2014-7169。

这个漏

查看全文: http://www.udpwork.com/item/13318.html

+0  追踪CPU跑满

Tag: 工作故事 | 操作系统 | hugepages | perf | sysrq-trigger
RobinDong 发于 2014年04月24日 17:54 | 点击: 1003 | 展开摘要
最近测试一个应用遇到问题:一旦压力略涨,应用的CPU就顶满。由于是多线程应用,直接就把系统的CPU耗完了。

本来想用gdb來调试的,结果gdb不给力,就在attach那里卡死,半天不动。后来想到了用perf来调试,果然找到了一处性能热点。修复热点以后,CPU顶满的问题缓解了一些,不太容易出现了,但是,多跑一会儿,还是会有。而且现在出现CPU顶满时,不仅gdb不返回,连perf record -a -g都无法用Ctrl+c来停止了,仔细top命令看了一下,原来系统的sys是1

查看全文: http://www.udpwork.com/item/12173.html

+0  LSF/MM Summit 2014

Tag: 业界分享 | 操作系统 | LSF | SMR | xfs
刘, 铮 发于 2014年04月02日 16:09 | 点击: 1077 | 展开摘要
作者:刘峥

今年LSF/MM会议的内容lwn.net上已经有文章进行详细的介绍了。鉴于我本人分身乏术造成mm track基本没有听,同时会上讨论的有些问题本人理解也十分有限,所以推荐大家还是去lwn.net上看一下上面的文章。这里仅仅是总结我认为比较重要和关注的问题,希望通过这篇文章能让大家了解目前Linux Kernel在文件系统、存储和内存管理方面需要解决的问题。

这次的LSF/MM会议的议题基本可以分为三个大的部分:

Linux Kernel目前存在的问题

来自

查看全文: http://www.udpwork.com/item/12057.html

+0  tpps: 一个可做cgroup资源隔离的高效IO调度器

Tag: 操作系统 | io scheduler | SSD | tpps
RobinDong 发于 2014年01月06日 15:16 | 点击: 1789 | 展开摘要
(本文里说的“资源隔离”主要是指cgroup根据blkio.weight的值来按比例调配io的带宽和IOPS,不包括io-throttle即blkio.throttle.xxx的一系列配置,因为linux的io-throttle机制不依赖于IO调度器)

由于现在的SSD越来越快也越来越便宜,如何高效的利用SSD就变得十分重要。高效利用SSD有两个办法,一个是加大应用程序发出的io深度(比如用aio),对于无法加大io深度的一些重要应用(比如mysql数据库),则可以用第二个

查看全文: http://www.udpwork.com/item/11484.html

+0  linux默认kernel.pid_max值

Tag: 操作系统 | pid_max | possible cpu
RobinDong 发于 2014年01月02日 15:20 | 点击: 2713 | 展开摘要
今早石祤同学发现了一个问题:同样的两台服务器,相同的OS版本、内核版本、CPU型号、CPU核数,只是厂家不同,但是机器启动后sysctl里的kernel.pid_max值,一台是128k,一台是32k。看了一下/etc/sysctl.conf,两台都没在配置文件里做更改,应该是内核自己选定的默认值。那内核到底是怎样选定这个默认值的呢?为何两个厂家的服务器默认值就不同?怎么让它们一致?

看了一下内核代码,决定kernel.pid_max的值是在pidmap_init()函数里

查看全文: http://www.udpwork.com/item/11456.html

+0  旧文件干扰

Tag: 操作系统 | version.h | 内核编译
RobinDong 发于 2013年11月19日 10:03 | 点击: 1219 | 展开摘要
昨天直接从git源上update到最新upstream内核版本,编译的内核却无法启动。一开始我以为是.config文件不对,于是试了各种方法,make localmodconfig,甚至make allmodconfig,居然还是起不来。于是在grub里加了个" vga=771 ",看看启动失败的具体报错信息,发现里面有句:

kernel tool old

神奇,这3.12的内核还老啊,在google上找了一下,还真有人遇到同样的报错,文章, 不过他是在arm上编译,gc

查看全文: http://www.udpwork.com/item/11148.html
|<<<1234567>>>| 一共9页, 105条记录