从cifs客户端删除一个文件

通过CIFS协议mount了一个目录过来。

删除文件后，发现该目录下又冒出一个以cifs开头无扩展名的特殊文件，其创建时间与我刚删除的文件保持一致。

通过stat看，inode节点值不同，但是创建时间，文件大小一样，内容也一样。

再删除，仍然是成功，但是同理，是该文件没了，多了一个新的cifs开头的临时文件。

后来用fuser看的时候，发现一点点端倪。

貌似是有另一个程序在open该文件，没有关闭，所以这边删除，那边samba的server不干了，改头换面又出现了。

把那个程序关闭重启后，再删除此文件，则不出现失而复得的问题。

恐怕是samba的bug，或者是考虑不周。

我的环境：

[enews@myhostname~]$ uname -a

Linux myhostname 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

[enews@i0gtw1 ~]$ rpm -qa|grep samba

samba-common-3.0.28-0.el5.8

samba-3.0.28-0.el5.8

samba-client-3.0.28-0.el5.8

system-config-samba-1.2.39-1.el5

samba-common-3.0.28-0.el5.8

[enews@i0gtw1 content]$ /sbin/fuser -v cifs5eab

Cannot stat file /proc/1902/fd/233: No such file or directory

Cannot stat file /proc/1902/fd/254: No such file or directory

Cannot stat file /proc/1902/fd/288: No such file or directory

[enews@i0gtw1 content]$ ll /proc/1902/fd/{233,254,288}

lr-x------ 1 enews enews 64 01-19 12:30 /proc/1902/fd/233 -> /enewsdc/datacenter/sms_gateway/xhsbjxt/content/XHSBJXT20110118_7942109.xml (deleted)

lr-x------ 1 enews enews 64 01-19 12:30 /proc/1902/fd/254 -> /enewsdc/datacenter/sms_gateway/xhsbjxt/content/XHSBJXT20110118_7942109.xml (deleted)

lr-x------ 1 enews enews 64 01-19 12:30 /proc/1902/fd/288 -> /enewsdc/datacenter/sms_gateway/xhsbjxt/content/XHSBJXT20110118_7942109.xml (deleted)

2009年3月发现的一个nfs caching问题

这是一个老问题了，超过21个月之后，重新拿出来记录一下。

问题出现在2009年，在2009年3月12-15日期间，专门针对此问题向网闸和操作系统的厂商提交了问题，经过多次邮件交涉(GMAIL有记录)，最终对问题有了基本认识。当时邮件不少，却没有汇总报告，今天刚好想起来就简单汇总一下。

此问题的现象是，在nfs server上能看到/ datacenter/collected/test/flag下面有文件，但是在nfs client上看不到。

文件送到server上用的是ftp协议，一个java程序在轮询flag目录，发现有新文件就处理掉。结果就是文件已经存在很久了，程序就是找不到该文件，用ls也看不到。

最开始怀疑问题出现在穿透网闸，再后来把测试程序写出来以后，在不走网闸的情况下，也会出现问题，只是频率不同而已，因此最终把火力瞄准了nfs，而不是网闸。

共享用的是nfs协议，开始以为是nfs server有问题，后来查找资料，发行是nfs client的caching问题。

To free pagecache, use echo 1 > /proc/sys/vm/drop_caches; to


free dentries and inodes, use echo 2 > /proc/sys/vm/drop_caches;


to free pagecache, dentries and inodes, use echo 3 >


/proc/sys/vm/drop_caches.




Because this is a non-destructive operation and dirty objects


are not freeable, the user should run sync(8) first.

在问题出现时，用ls命令是看不到文件的，但是如果知道确切文件名的话，可以用stat命令显示该文件的信息，但是如果stat *仍然看不到，在nfs server上则所有问题都不存在，说明文件确确实实写到磁盘上了。

处理办法：

1，改用cifs共享方式。CIFS协议无此问题。我最终选用了这个方案。

2，定时touch一下flag目录，这个方法最简单，且普通用户就可以了。

3，定时清缓存。如果去清除cache，有可能会导致脏数据丢失，因此必须事先发出sync命令，且必须以root来执行。个人觉得这个方法不现实，频率掌握不了，且需要root权限，就没做详细测试。

经验值：测试程序非常重要，专门写的制造此问题的程序，可以在公司的实验环境中将问题复现出来，且频率提高以后，还可以将网闸等非关键要素给筛选过滤出局。

问题的终极解决办法，估计需要等nfs协议的v4版本NFS v4 (pNFS)来彻底解决，并且在v4本身已经采用了全新的协议方式，估计可以从根本上避免此问题。实际上，v4发展的是相当的慢。

移动互联网在美国人掌控之中

在智能手机市场最常见的操作系统有苹果iOS、谷歌Android、塞班(Symbian)、Windows Mobile和黑莓OS等，由于可以安装第三方软件，因此智能手机具有非常丰富的功能。

移动互联网，将是未来几年最火爆的领域。截至2010年，最牛大的5款智能手机操作系统，有4款是美国人控制的，Symbian是芬兰人的。如果加上Palm系统，那又是一个美国。

不能不佩服，硅谷的强大创新动力。或者是美国的风险投资，或者是Nasdaq，嗯，都很强大。

撤出microsoft live spaces空间

由于微软于2010年9月28日发布消息，将关闭 live spaces，我也不得不开始整理几年来写的东西，准备撤离。

9月28日微软将关闭Live Spaces 拟转移3000万用户http://www.enet.com.cn/article/2010/0928/A20100928741042.shtml

以前在很多个网站都留下过脚印，尝试过很多博客空间，实在是有很多东西都不记得了，地址和账号都忘记，或者只记得部分信息的太多了。目前能汇集到一起的数据，也只有2个live.spaces.com的内容，还有2个blogspot.com的内容。不过这样也不错了，汇总了这几年写的不少东西。以下数据也是目前能够汇总的数据了。

1，开始写是2005年1月份。

2，开始的时候写的多一点，在2006年发帖量最大，不过大多数是转帖和一些牢骚。

3，到现在累积出260条左右的文章，其中有不少是copy/paste模式。2005-43,2006-117,2007-41,2008-23,2009-24,2010-12

4，现在基本上在努力保持每月一条（网友称之为月经贴）。

5，微博账号在2010年qq上激活。未注册新浪，twitter/facebook由于被封，无访问量的SNS网站几乎等于不存在，导致我的账号都已经不记得了。

最后，争取把所有文章汇总到这两个地方（互为备份，免得再倒闭关张）：

• http:// zhangjiansheng.wordpress.com
• http:// zhangjiansheng.blogspot.com

云计算和服务器集群的关系

2008.09.25 周鸿祎语出惊人，"一家企业没有1000台以上的服务器，就不要妄谈'云安全'。"


http://tech.163.com/08/0925/10/4MM87M3V000915BF.html

2010.06.25 他们自己装的超过100万台组成的计算机群是Google的真正核心竞争力。Skype做的电话系统是一个非常标准的云计算平台。


http://tech.sina.com.cn/it/2010-06-25/15364352038.shtml

不管是数据中心，还是服务器集群，还是超算，还是超级计算机，还是云计算，都是提供高效率的后台计算能力，这些就是未来IT业务的核心。至于端，目前最火的莫过于iPhone/iPad/gPhone/xPhone之类的移动终端了，个人理解基于HTML5的浏览器也会带来PC端的提升。可以预计的个人未来几年的工作，都会与之有关。

mysql的timestamp字段

在5.0和5.1版本上都发现了这个warning，记录一下。

根据bug报告记录显示，"WIN XP Professional" with MySQL 6.0.8Alpha版本上，干脆是直接fail掉了。

http://bugs.mysql.com/bug.php?id=41510

Server version: 5.1.32-log MySQL Community Server (GPL)

Your MySQL connection id is 124144 to server version: 5.0.27-standard-log

mysql> CREATE TABLE test1 (updatetime timestamp(14) DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP) ENGINE = InnoDB;


Query OK, 0 rows affected, 1 warning (0.01 sec)

mysql> show warnings;

*************************** 1. row ***************************


Level: Warning


Code: 1287


Message: 'TIMESTAMP(14)' is deprecated; use 'TIMESTAMP' instead


1 row in set (0.00 sec)

同时，TIMESTAMP字段是个很神奇的东西，值得copy一下其使用规则。

TIMESTAMP值显示尺寸的格式如下表所示：


　　：


　　+---------------+----------------+


　　| 列类型　　　　| 显示格式　　　 |


　　| TIMESTAMP(14) | YYYYMMDDHHMMSS |　


　　| TIMESTAMP(12) | YYMMDDHHMMSS　 |


　　| TIMESTAMP(10) | YYMMDDHHMM　　 |


　　| TIMESTAMP(8)　| YYYYMMDD　　　 |


　　| TIMESTAMP(6)　| YYMMDD　　　　 |


　　| TIMESTAMP(4)　| YYMM　　　　　 |


　　| TIMESTAMP(2)　| YY　　　　　　 |


　　+---------------+----------------+


　　"完整"TIMESTAMP格式是14位，但TIMESTAMP列也可以用更短的显示尺寸创造


　　最常见的显示尺寸是6、8、12、和14。


　　你可以在创建表时指定一个任意的显示尺寸，但是定义列长为0或比14大均会被强制定义为列长14。


　　列长在从1～13范围的奇数值尺寸均被强制为下一个更大的偶数。


　　


　　列如：


　　定义字段长度　　 强制字段长度


　　TIMESTAMP(0) ->　TIMESTAMP(14)


　　TIMESTAMP(15)->　TIMESTAMP(14)


　　TIMESTAMP(1) ->　TIMESTAMP(2)


　　TIMESTAMP(5) ->　TIMESTAMP(6)


　　


　　所有的TIMESTAMP列都有同样的存储大小，


　　使用被指定的时期时间值的完整精度（14位）存储合法的值不考虑显示尺寸。


　　不合法的日期，将会被强制为0存储

你可以非常灵便地确定什么时候初始化和更新TIMESTAMP和对哪些列进行初始化和更新：例子，下面这些语句是等效的：

CREATE TABLE t (ts TIMESTAMP);


CREATE TABLE t (ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP);


CREATE TABLE t (ts TIMESTAMP ON UPDATE CURRENT_TIMESTAMP DEFAULT CURRENT_TIMESTAMP);

7月8日发布的Java 1.6.0_21，当月12日就爆出崩溃问题

昨天(2010年8月2日)看到的消息，Java 1.6.0_21有不少非技术问题，不是很稳定，建议暂时不要更新，当天外网电脑已经有此版本的更新提示了。

Java SE 6 Update 21发布 修复大量安全漏洞

美国太平洋时间2010年7月8日美国甲骨文公司发布Java SE 6 Update 21，简称：6u21。此更新的完整版本的内部版本是1.6.0_21-b06（其中"B"的意思是"Build--建设"）。外部版本号是6u21。（51CTO独家专题推荐：Java EE 6平台指南）

http://developer.51cto.com/art/201007/210679.htm

甲骨文的Java更换企业名称导致Eclipse崩溃

在Java 1.6.0_21中，Java的公司字段从"Sun Microsystems, Inc"改为了"Oracle."，但这一改动却导致了始料未及的后果：因为有些应用程序是需要依靠公司字段识别虚拟机。集成开发工具Eclipse 3.3版后的版本，包括刚刚发布的Eclipse Helios，都由于这一改变而报OutOfMemoryError错误，因此而发生崩溃。Java是通过自动更新程序更新的。

http://it.solidot.org/article.pl?sid=10/07/29/102249