我有一个文件服务器，其中DF报告94％/完整。 但根据杜，更less使用： # df -h / Filesystem Size Used Avail Use% Mounted on /dev/sda3 270G 240G 17G 94% / # du -hxs / 124G / 我读了开放但删除的文件可以负责，但重启没有解决这个问题。 这是Linux，ext3。 问候
有没有人见过这个？ 我有一个突袭5安装在我的服务器上，无论出于什么原因，它开始显示： jason @ box2：/ mnt / raid1 / cra $ ls -alh ls：无法访问e6eacc985fea729b2d5bc74078632738：input/输出错误 ls：无法访问257ad35ee0b12a714530c30dccf9210f：input/输出错误 总计0 drwxr-xr-x 5 root root 123 2009-08-19 16:33。 drwxr-xr-x 3 root root 16 2009-08-14 17:15 ?????????? ？ ？ ？ ？ ？ 257ad35ee0b12a714530c30dccf9210f drwxr-xr-x 3 root root 57 2009-08-19 16:58 9c89a78e93ae6738e01136db9153361b ?????????? ？ ？ ？ ？ ？ e6eacc985fea729b2d5bc74078632738 md5string是实际的目录名称，不是错误的一部分。 问号很奇怪，当你试图使用/删除/ etc时，带有问号的任何目录都会抛出io错误。 […]
最近，我看到由于一致性问题，远程数据中心中的计算机的根文件系统被重新安装为只读。 重新启动时，显示此错误： UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (ie, without -a or -p options) 按照build议运行fsck后，用Y手动接受修正，错误得到纠正，系统现在正常。 现在，我认为如果fsck被configuration为自动运行并修复所有内容，这将是一件有趣的事情，因为在某些情况下（比如这个）唯一的select是亲自到远程数据中心，并将控制台连接到受影响的机器。 我的问题是：为什么默认fsck要求手动干预？ 如何以及何时由这样的程序进行更正将是不安全的？ 当系统pipe理员可能想在一段时间内抛开build议的修正（执行一些其他操作）或将其全部中止时，有哪些情况？
当你创build一些像ext3这样的Linux文件系统时，会创build一个“lost + found”目录。 根据这个文件将被放置在那里，如果文件被某种系统崩溃损坏。 如果删除该目录，系统将会崩溃。 如果该文件夹被删除，我可以创build一个新的目录，其中mkdir lost + found，或者只有在文件系统创build时才能设置属性。
我正在使用Ubuntu 12.04，无法写入任何文件，甚至作为根，或做任何其他需要写作的操作。 任何需要编写的程序都不能，所以它们都失败了。 df说我有足够的空间： Filesystem Size Used Avail Use% Mounted on /dev/xvda1 30G 14G 15G 48% / udev 984M 4.0K 984M 1% /dev tmpfs 399M 668K 399M 1% /run none 5.0M 0 5.0M 0% /run/lock none 997M 0 997M 0% /run/shm 我发现的所有结果“无法写入磁盘”都是关于合法的完整磁盘。 我甚至不知道从哪里开始。 这个问题今天早上从无处出现。 PHP的最后一个日志条目是： 失败：设备上没有剩余空间（28） Vim说： 无法打开（文件）进行写入 其他应用程序也有类似的错 为了确定删除〜1GB，问题依然存在。 我也重新启动。 df -i说 Filesystem Inodes […]
哪些字符是允许的，哪些字符必须在不同操作系统的命令行上转义？
众所周知，你永远不应该挂载一个挂载的分区。 我可以理解，如果通过fsck 写入文件系统（例如，使用-a选项），这很容易导致损坏，但是为什么不能在已挂载的磁盘上运行只读检查？
不知何故，我们之前的Server 2008（不是R2）盒子已经开发了一个看似无限recursion的文件夹。 这是与我们的备份玩破解，因为备份代理试图递减到文件夹，永远不会返回。 文件夹结构如下所示： C:\Storage\Folder1 C:\Storage\Folder1\Folder1 C:\Storage\Folder1\Folder1\Folder1 C:\Storage\Folder1\Folder1\Folder1\Folder1 … 等等。 这就像90年代我们曾经玩过的Mandelbrot套装中的一个。 我试过了： 从资源pipe理器中删除它。 是的，我是一个乐观主义者。 RMDIR C:\Storage\Folder1 /Q/S – 这个返回The directory is not empty ROBOCOPY C:\temp\EmptyDirectory C:\Storage\Folder1 /PURGE – 在robocopy.exe崩溃之前，这将在文件夹中旋转几分钟。 任何人都可以build议一种方法来杀死这个文件夹好？
我们正在考虑build立一个〜16TB的存储服务器。 目前，我们正在考虑将ZFS和XFS作为文件系统。 有什么优点和缺点？ 我们需要寻找什么？ 有第三个更好的select吗？
我已经将XFS文件系统作为数据/增长分区在各种Linux服务器上运行了近10年。 最近CentOS / RHEL服务器运行的版本是6.2+，我注意到了一个奇怪的现象。 随着从EL6.0和EL6.1迁移到较新的操作系统版本，稳定的文件系统使用变得高度可变。 最初与EL6.2 +一起安装的系统performance出相同的行为; 在XFS分区上显示磁盘利用率的大幅波动（请参阅下图中的蓝线）。 之前和之后。 星期六从6.1升级到6.2。 过去一个季度的同一系统的磁盘使用情况图显示了上周的波动情况。 我开始检查文件系统的大文件和失控进程（日志文件，也许？）。 我发现我最大的文件报告du和ls不同的值。 使用和不使用–apparent-size开关的du运行说明了不同之处。 # du -skh SOD0005.TXT 29G SOD0005.TXT # du -skh –apparent-size SOD0005.TXT 21G SOD0005.TXT 在整个文件系统中使用ncdu实用程序进行快速检查，结果如下： Total disk usage: 436.8GiB Apparent size: 365.2GiB Items: 863258 文件系统中充满了稀疏的文件 ，与之前版本的OS /内核相比，有将近70GB的空间丢失！ 我通过红帽Bugzilla进行了更新，并更改了日志，以查看是否有任何有关XFS的相同行为或新通告的报告。 纳达。 在升级过程中，我从内核版本2.6.32-131.17.1.el6升级到2.6.32-220.23.1.el6 ; 次版本号没有变化。 我用filefrag工具检查了文件碎片。 一些XFS分区上最大的文件有数千个扩展盘区。 在缓慢的活动期间使用xfs_fsr -v在线碎片整理运行帮助暂时减less磁盘使用（请参见上面的第一个图表中的星期三）。 但是，尽快重新启动系统活动，使用量会大增。 这里发生了什么？