最近我们在存储方面有失败，我们需要fsck。 存储大约1.2万亿，花了我们5个多小时。 有没有ext3文件系统的替代解决scheme，还是比ext3更好？ 有正反两面的build议是值得欢迎的。 TQVM
在CentOS 5.3服务器上，/ var文件夹已经更改为文件。 似乎是FS腐败。 其余的FS看起来不错。 任何人都知道解决这个问题的快速方法？ 即使使用强制检查，fsck.ext3也会将fs报告为干净。 看起来机器有动力，当它回来时就是这样。
意外地写了/ dev / zero到500GB磁盘的第一个371MB。 是否有可能重build分区表和/或恢复哪些数据没有被覆盖？
我读了一些与这个问题有关的答案。 如果系统分区在短时间内无法访问，操作系统是否会崩溃？ 但是我解决不了这个问题 如果在XenServer上使用ISCSI作为存储库，并且DomU（VM）处于繁重的磁盘I / O中，如果ISCSI连接丢失（主要是networking连接问题/存储故障转移），则DomU文件系统（特别是ext3 linux文件系统）崩溃。 在这种情况下，DomU的ext3文件系统变成只读或不可恢复的。 如何在Dom0连接丢失的情况下保护虚拟机的文件系统？ 这是我的XenServer环境。 [root@cnode01-m ~]# iscsiadm -m session tcp: [1] 10.32.1.240:3260,2 iqn.1986-03.com.sun:02:c5544ae6-9715-6f38-f83b-a446896ac614 tcp: [3569] 10.32.1.240:3260,2 iqn.1986-03.com.sun:02:5c41ce31-3fbb-c6aa-d479-947e85515ac7 [root@cnode01-m ~]# vgs VG #PV #LV #SN Attr VSize VFree VG_XenStorage-1aeee13b-2a87-1d0d-1834-7b8c868009b0 1 40 0 wz–n- 6.35T 4.93T VG_XenStorage-28e2c663-dae5-9504-9733-e05063ff081d 1 57 0 wz–n- 6.35T 4.52T VG_XenStorage-365d6e13-5caa-1fea-9940-e1bb553e3513 1 42 0 wz–n- 6.35T 5.13T VG_XenStorage-4ea23f9a-f945-5d45-cbd2-f3eab3fe75b3 […]
当在Linux（2.6.18）中对文件的随机读I / O进行基准testing时，我注意到了奇怪的问题。 Benchmarking程序是我自己的程序，它只是从一个随机的偏移量中读取16KB的文件。 我通过systemtap跟踪了系统调用级别和scsi级别的I / O行为，并注意到一个16KB的sysread会发出2个scsi I / O，如下所示。 SYSPREAD random(8472) 3, 0x16fc5200, 16384, 128137183232 SCSI random(8472) 0 1 0 0 start-sector: 226321183 size: 4096 bufflen 4096 FROM_DEVICE 1354354008068009 SCSI random(8472) 0 1 0 0 start-sector: 226323431 size: 16384 bufflen 16384 FROM_DEVICE 1354354008075927 SYSPREAD random(8472) 3, 0x16fc5200, 16384, 21807710208 SCSI random(8472) 0 1 0 […]
我有一个ext3分区，所以当我这样做： mount /dev/blah /mnt/blah 它会自动挂载为ext3。 我可以通过运行将它挂载为ext4 mount -t ext4 /dev/blah /mnt/blah 它的工作。 我认为分区标记为ext3。 是否有可能将其更改为ext4，以便： mount /dev/blah /mnt/blah 将它挂载为ext4。 这是一个实验。 我想在不启用ext4中的新function的情况下这样做，所以我可以回到ext3。
我有一台CentOS 6x服务器并在其上运行Java应用程序，应用程序正在使用一个挂载点/ javapp，这是一个EXT4文件系统。 突然我在系统日志中出现以下错误： 内核：尝试访问超出设备端 内核：dm-2：rw = 0，want = 34359697536，limit = 112984064 我发现这个错误可能是由两种可能的情况之一造成的： 存储大小调整（例如，LVM或SAN） 腐败者文件系统 所有的指针都表明文件系统损坏，因为我没有改变任何支持磁盘的大小。 我的问题是，应用程序是否能够破坏文件系统？
我在软件raid5（md）之上创build一个ext3文件系统，我想知道创build文件系统（使用mkfs.ext3）和安装时最好的参数是什么。 RAID5块大小为128k，arrays有3个驱动器，有效总数为900 GB。 ext4不是一个选项。 编辑：文件系统有几个VPS（虚拟私人机器），包括一个Gentoo VPS与很多很多小文件。 VPS不使用图像，它们直接在文件系统上存储文件。 它也有很多500-1000 MB的文件。 谢谢，马蒂奇
鉴于这个主题的特殊性质（我们不是在谈论邮箱，只是假脱机，我们不是在谈论其他的文件系统，只是ext3，等等…）和相关软件的成熟（linux内核，ext3fs，postfix）我认为应该有一个或多或less的文件系统相关调优的最佳做法。 我正试图对他们进行综合： data=journal成了最近内核的默认版本（大约2.6.30 IIRC），所以我们应该可以 Wietse Venema说atime必须打开，但Postfix文档build议在讨论入站队列时不要使用noatime 。 这是否意味着postfix只需要一些队列目录的一段时间，并会从其他时间的noatime受益？ 如果我们不使用ETRN，我们可以使用noatime吗？ 文件系统可以挂载nodev,noexec,nosuid – no *不会阻止你设置属性（postfix使用exec attr），它们只是没有任何作用（我们不会从spool中运行任何东西） Wietse和/或chattr -S引用的fsync()问题可能与ext3fs的sync / async选项有关，但是我不太了解它们。 使用async选项login文件系统相当于chattr -R -S整个fs？ 似乎它会提高性能，但这会冒着“ 系统崩溃后丢失邮件 ”的风险，还是真的在/ var / spool / postfix上安全？ 你会调整其他任何postfix-2.6.x在ext3上更好地工作，或者你在任何地方都保留默认值吗？ 有没有一个“最好”的Linux I / O调度器这种工作量（即CFQ或截止date？），或者这将根据硬件configuration变化太多？ 你会调整文件系统或内核中的其他东西吗？ 还要别的吗？ 参考文献： SF上的Postfix性能 有关入站队列的 Postfix文档 Wietse Venema在[email protected]上的最佳文件系统 Postfix和ext3在[email protected] 这里和那里
我在大型ext3文件系统上粉碎文件（例如，请参阅这篇文章以了解如何执行此操作）。 为了实现这一点，我需要挂载ext3文件系统而不logging。 对于大多数人来说，我只需卸载它们，然后重新安装它们作为ext2即可。 但某些文件系统无法卸载（例如/），并尝试使用“-o remount，data = writeback”失败，并显示错误。 是否可以closures安装的ext3文件系统的日志，而无需卸载它？