系统有个目录/data，任何用户向这个目录（及其子目录）拷贝文件的时候
如果文件大于32768bytes的时候都会报错，并且只拷贝32768bytes然后终止
例如：
hostname#cp /smit.log smit.log.bk
cp: smit.log.bk: There is not enough memory available now.
hostname#ls -al
-rw-r--r-- 1 root dba 32768 May 17 16:35 smit.log.bk
什么原因？
| hou007 回复于：2005-05-17 16:49:14 |
| 提示内存不够了,可以停掉几个进程.或者重新启动. |
| china13 回复于：2005-05-17 16:53:21 |
| 晕 提示不是很明显么。内存不够 |
| leyearn 回复于：2005-05-17 18:21:24 |
| 没楼上两位说的那么简单
当使用root用户或其他的用户，向其他的目录cp任何大的文件，都能够成功 也就是说每当向这个目录cp东西的时候就会出现 hostname#cp /smit.log smit.log.bk cp: smit.log.bk: There is not enough memory available now. hostname#ls -al -rw-r--r-- 1 root dba 32768 May 17 16:35 smit.log.bk 整个文件系统都这样，把这个文件系统里的文件拷贝到其他的文件系统里也不存在问题！ 现在问题是这样的： 1.不是内存的问题，系统内存还有2G 2.我觉得不是用户的问题，不同的用户都会遇到一样的问题 现在是文件系统的问题 文件系统的属性是 drwxr-sr-x /data 其下的所有子目录也是这样的属性！ |
| havent_bao 回复于：2005-05-17 22:37:17 |
| ulimit -Sa
ulimit -Ha 也许你就找到这个数字了，那就是原因了。 |
| leanron 回复于：2005-05-17 23:32:54 |
| 好像不是楼上说的各种原因，具体原因帮你顶…… |
| leyearn 回复于：2005-05-18 08:28:31 |
| cws:/etc/security>ulimit -Sa
time(seconds) unlimited file(blocks) unlimited data(kbytes) 131072 stack(kbytes) 32768 memory(kbytes) 32768 coredump(blocks) 2097151 nofiles(descriptors) 2000 看到了32768，如果要解决我这个问题，需要更改这个32768这个参数吗 怎么更改，更改之后有没有副作用？ 谢谢 |
| leyearn 回复于：2005-05-18 09:23:02 |
| 并没有做什么限制（出现问题这台机器），上一个帖子是在另外一台机器上执行的
jszx2#ulimit -Ha time(seconds) unlimited file(blocks) unlimited data(kbytes) unlimited stack(kbytes) unlimited memory(kbytes) unlimited coredump(blocks) unlimited nofiles(descriptors) unlimited jszx2#ulimit -Sa time(seconds) unlimited file(blocks) unlimited data(kbytes) unlimited stack(kbytes) unlimited memory(kbytes) unlimited coredump(blocks) 2097151 nofiles(descriptors) 2000 jszx2# |
| 强人 回复于：2005-05-18 09:46:20 |
| 帮顶 |
| xzhj19 回复于：2005-05-18 11:19:47 |
| 从输出看好像没有软硬资源极限问题，是文件系统属性的问题吧？
不太清楚，帮你顶！ |
| redandblack 回复于：2005-05-18 12:38:18 |
| 帮顶！ |
| leyearn 回复于：2005-05-18 14:12:20 |
| 刚才fsck了一下这个文件系统，结果如下：
jszx2#fsck /dataxlt ** Checking /dev/fslv00 (/datax) MOUNTED FILE SYSTEM; WRITING SUPPRESSED; Checking a mounted filesystem does not produce dependable results. ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Inode Map Bad Inode Map (NOT SALVAGED) ** Phase 6 - Check Block Map Bad Block Map (NOT SALVAGED) Filesystem integrity is not guaranteed 102057 files 223007744 blocks 77409280 free 好象有问题！ 这个文件系统200G还多 大家给个方案怎么修复呢？ |
| daniel_w 回复于：2005-05-18 14:29:09 |
| 是不是I节点的分配问题？ |
| zlg88 回复于：2005-05-18 16:43:30 |
| I节点的问题. |
| ar6400 回复于：2005-05-18 17:29:50 |
| 先备份一下文件系统：backup -f /tmp/data.bak -'0' /data
卸载文件系统：umount /data 检查文件系统：fsck /data 注意有报错时，回答Y修复。如果太多，就用 fsck -y /data |
| leyearn 回复于：2005-05-20 19:07:03 |
| 感谢各位的大力支持
确实是文件系统出了问题 #fuser -cukx /dataxlt #umount /dataxlt #fsck -y /dataxlt #mount /dataxlt ok now |
| daichuang 回复于：2005-05-25 09:12:29 |
| 確實如此,我也遇到過類似情況. |
| oscarhoya 回复于：2005-05-27 15:30:17 |
| 路过,未遇,帮顶 |
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
