哪些字符对ext3文件名无效？ 我想至less/是一个无效的字符，可能\0 。 有没有正式的清单？ 我不确定在哪里寻找这些信息，所以请告诉我你在哪里find它。
所以，就是这样。 一切正常，除了磁盘只读，不想改回来。 ^ _ ^！ 谢谢。 root@NODE02:/tmp# df . Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda5 461490504 179502128 258545928 41% / root@NODE02:/tmp# mount -o rw,remount /dev/sda5 mount: cannot remount block device /dev/sda5 read-write, is write-protected root@NODE02:/tmp# touch helll touch: cannot touch `helll': Read-only file system 这不是多path。 没什么特别的 只是一个服务器与Ubuntu 9.10。 对我来说没有意义，是吗？ – – 编辑 – […]
我无法使用包含超过127个西里尔文UTF-8符号的名称保存文件在我的Ext3文件系统上。 尽pipe如此，可以保存包含255个英文UTF-8符号的文件。 那么，包含文件名或文件名中字符数的字节数是否有限制？ 例如，对于前者，人们会期望中文文件名的长度受到更严格的限制。 是对的吗？
背景 ：我在CentOS 5.3上运行lighttpd 1.4.28-1来提供静态资产。 信号 ：最近有时会变慢。 我在内核日志和/var/log/messages得到了下面的错误： proftpd[5145]: (::ffff:xx[::ffff:xx]) – FTP session opened. proftpd[5145]: (::ffff:xx[::ffff:xx]) – Preparing to chroot to directory 'xx' EXT3-fs warning (device dm-3): ext3_dx_add_entry: Directory index full! Sep 16 15:30:34 xx last message repeated 489 times inode信息： df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/mapper/ddf1_p3 77037568 9996012 67041556 13% / […]
我使用rsnapshot为我的“工作”共享创build每小时/每天/每周/每月的备份。 现在我试图使用rsync将整个备份目录复制到外部驱动器上。 我使用这个命令/参数在一个屏幕会话（是的，rsync-exclude.txt位于我运行命令的目录） rsync -avzHP –exclude-from 'rsync-exclude.txt' /share/backup/ /share/eSATADisk1/backup/; 整个东西在QNAP TS-439上运行，内部驱动器是一个单一的磁盘（没有RAID）EXT4格式化，外部驱动器形成EXT3。 会发生什么情况是：Rsync跟随每个硬链接并复制实际的文件，而不是重新创build外部驱动器上更新的硬链接 。 我没有马上意识到这一点，所以外部驱动器最终被同一个文件的xxx副本丢弃了。 我想实现的是：将由rsnapshot生成的整个文件结构复制到外部驱动器，保持硬链接节省空间。 注意：这不一定是使用rsync完成的。 感谢您的想法和时间。 我很感激你的帮助，大的时间。 更新：我知道，rsnapshot没有使用符号链接，它使用硬链接，所以我现在使用-H选项，它应该根据Rsnapshot保存硬链接结构到多个目的地（或维护硬链接结构），但它仍然不会工作…我在这里错过了什么？ 更新2：在这里我发现了另一个关于这个话题的观点/陈述： rsync和–hard-links冻结了 Steven星期一build议不要尝试rsync包含硬链接的大文件结构，因为它吸收了很多内存，对于rsync来说是一件很难的事情。 所以可能更好的解决scheme是制作一个.img数据结构，我试图备份。 你怎么看？
在我的Intranet服务器上，我有一个100.00 GiB分区/ dev / sda5，我用它作为lvm2的物理卷。 这是我的卷组vg01中唯一的物理卷。 vg01目前包含一个逻辑卷lv01，使用完整的100.00 GiB – 好，实际上99.99 GiB由于一些四舍五入（这是问题的开始）。 lv01包含一个ext3文件系统，使用整个空间。 我想将lv01降低到大约97吉比特，所以我可以创build约lv02。 3 GiB（我需要它采取lvm快照）。 我到目前为止做了什么： e2fsck -f /dev/mapper/vg01-lv01 resize2fs /dev/mapper/vg01-lv01 97G 这工作得很好。 但现在我必须跑 lvreduce –size ? /dev/mapper/vg01-lv01 而且我不确定，我必须指定哪个确切的值。 lvreduce手册页明确警告，生成的大小不能小于文件系统。 我也不想把它做得比它大。 但现在我有不同的数字： 我在resize2fs中指定了97G 。 df -h说，它是96 G. df说，这是100115936 1K块。 lvdisplay（当然）仍然报告逻辑卷99.99 GiB。 我需要为lvreduce指定lvreduce ？ 编辑： 目前接受的答案提供了一个很好的解决方法。 但是，为了将这些东西整合到实体脚本等中，我通常宁愿使用精确的测量。 或者，也许已经有一个可靠的（！）脚本或工具，一步执行整个resize的过程？
我正在做一个大规模的存储农场的设置，为了避免需要长达一个月的时间，我的计划是将存储分割成许多较小的文件系统（这很好，因为我有一个分段文件树，所以我可以很容易地在1/ ， 2/ ， 3/ ， 4/等上安装单独的文件系统）。 我的困难在于find文件系统的“合理”大小的任何枚举，以保持fsck时间类似“合理”。 尽pipe我完全意识到给定大小的绝对时间在很大程度上取决于硬件，但我似乎无法find任何有关不同文件系统大小的ext3 fsck时间曲线形状的描述，以及其他variables（一个文件系统在一个目录中的文件占用时间要长于树中数千个目录中的每个文件中的10个文件;大文件vs小文件;完整文件系统vs空文件系统;等等）。 有没有人有任何关于这方面的研究数字的参考？ 如果不这样做，那么有关这些问题的任何轶事至less应该有助于指导我自己的实验，如果这是必要的。 编辑 ：澄清：无论文件系统，如果元数据出现问题，它将需要检查。 无论是基于时间还是基于挂载的重新启动都没有问题，我要求提供有关ext3的数字的唯一原因是因为这是最有可能select的文件系统。 如果你知道一个fsck过程特别快的文件系统，我愿意提供一些build议，但是它确实需要一个强大的选项（声称“文件系统X永远不需要fscking！”将会被嘲笑和嘲笑） 。 我也意识到需要备份，fsck的愿望不能替代备份，但是只是丢弃文件系统，并在备份恢复时，而不是备份，似乎是一个真正愚蠢的折衷。
我从来没有真正支付块大小的注意力，但显然有select以外的东西可以有其他的好处。 我正在寻找一个很好的“最佳实践”论文select块大小。 而且，在LVM之上使用时，性能上的收益或重要性是否会被否定？ TIA
我在使用Dell 1950服务器时遇到了一些问题。 我在这里安装了RHEL 4.6以及Oracle和其他一些软件。 我随机得到一个错误消息，说：我的SSH会话和监视器上的“内核：日志提交I / O错误”，我已经连接到服务器，我看到一个滚动的错误说：“EXT3-FS错误（设备SDA5）在start_transaction：日记已经中止。“ 它已经发生了好几次，但从未在安装过程中的同一时刻。 实际上，系统最后一次启动和运行时，我只是试图将数据库导入到oracle中。 这发生在几个硬盘上，所以我很确定这不是问题。 这让我觉得RAID控制器坏了。 你们有什么感想？ **更新** 很确定这是一个坏的硬盘。 我扔了另一个驱动器的服务器，它已经运行了约48小时，出了问题。
我的公司生产一个embedded式的Debian Linux设备，可以从内置SSD驱动器上的ext3分区引导。 由于该设备是一个embedded式“黑匣子”，因此通常通过外接开关切断设备的电源，这种方式通常会被粗暴地closures。 这通常是可以的，因为ext3的日志logging保持有序，所以除了偶尔的日志文件部分丢失以外，事情一直保持顺畅。 然而，最近我们看到了许多单位，经过一些硬核循环之后，ext3分区开始出现结构性问题 – 特别是我们在ext3分区上运行e2fsck，并发现了一些类似的问题显示在本课题底部的输出列表中。 运行e2fsck直到它停止报告错误（或重新格式化分区）将清除问题。 我的问题是…在一个ext3 / SSD系统出现突然/意外关机的情况下，看到这样的问题有什么影响？ 我的感觉是，这可能是我们系统中的软件或硬件问题的标志，因为我的理解是（除了一个bug或硬件问题）ext3的日志loggingfunction应该能够防止这些文件系统完整性错误。 （注意：我知道用户数据没有被logging，所以可能会发生用户文件的删除/丢失/截断;我在这里具体讨论文件系统 – 元数据错误，如下所示） 另一方面，我的同事说，这是已知的/预期的行为，因为SSD控制器有时会重新sorting写入命令，并可能导致ext3日志混淆。 特别是，他相信，即使给出了正常运行的硬件和无缺陷的软件，ext3日志也只会使得文件系统损坏的可能性降低，而不是不可能，所以我们不应该感到惊讶。 我们哪一个是对的？ Embedded-PC-failsafe:~# ls Embedded-PC-failsafe:~# umount /mnt/unionfs Embedded-PC-failsafe:~# e2fsck /dev/sda3 e2fsck 1.41.3 (12-Oct-2008) embeddedrootwrite contains a file system with errors, check forced. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Invalid inode number for '.' […]