Questions tagged «ext3»

ext3是许多Linux发行版的默认文件系统。

2
我们应该在ext3上安装data = writeback和barrier = 0吗?
我们已经在托管公司的VM上运行服务器,并且刚刚注册了专用主机(AMD Opteron 3250、4核,8GB RAM,2 x 1TB的软件RAID,ext3)。 在运行性能测试时,我们注意到某些SQLite转换(插入,删除和/或更新的组合)所花的时间比我的2010 MacBook Pro长10倍至15倍。 经过大量的搜索和阅读之后,我们来看一下安装选项: data=ordered,barrier=1 我们做了一些实验,并获得了最佳性能 data=writeback,barrier=0 我已经阅读了这些内容,并了解了它们在做什么的基础知识,但是对于这样的跑步对我们来说是否是一个好主意,我没有一个很好的感觉。 问题 对于托管服务,上述配置是否明智? 如果发生断电或硬崩溃,那么最终可能会导致数据丢失或文件损坏。如果我们每15分钟对数据库快照一次,这可能会减轻这种情况,但是在拍摄快照时可能不会同步数据库。我们应如何(能够?)确保此类快照的完整性? 我们还应该考虑其他选择吗? 谢谢

2
SSD驱动器的ext3分区上的突然掉电后文件系统损坏是“预期行为”吗?
我公司制造了一个嵌入式Debian Linux设备,该设备从内部SSD驱动器上的ext3分区启动。因为该设备是嵌入式“黑匣子”,所以通常通过简单地通过外部开关切断设备电源来粗鲁地关闭它。 这通常是可以的,因为ext3的日志记录可以使事情井井有条,因此,除了偶尔丢失部分日志文件外,事情还可以继续进行。 但是,我们最近看到了许多单元,在经过多次硬重启之后,ext3分区开始出现结构性问题-特别是,我们在ext3分区上运行e2fsck,它发现了许多类似的问题显示在此问题底部的输出清单中。运行e2fsck直到停止报告错误(或重新格式化分区),都可以解决问题。 我的问题是...在遭受大量突然/意外关机的ext3 / SSD系统上看到类似问题的含义是什么? 我的感觉是这可能是我们系统中软件或硬件问题的迹象,因为我的理解是ext3的日记功能(除非存在错误或硬件问题)被认为可以防止这类文件系统完整性错误。(注意:我了解用户数据未记录日志,因此用户文件可能被蒙蒙/丢失/截断;我在这里专门谈论文件系统元数据错误,如下所示) 另一方面,我的同事说这是已知的/预期的行为,因为SSD控制器有时会重新排序写命令,这可能会使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 '.' in directory inode …

6
如何在Linux上列出文件的数据块?
据我了解,类Unix操作系统上的每个文件都有一个索引节点号(可以用“ ls -i”查看),每个索引节点是一个磁盘块列表,其中包含文件的实际数据。 是否有Linux命令以文件名作为参数并打印出该文件的inode指向的磁盘块列表? PS该文件系统是ext3。
13 linux  unix  filesystems  ext3 

2
在大型文件系统上运行fsck的内存不足
我照顾一个只有512 MB RAM的旧Debian linux盒(运行etch),但是连接了许多外部存储。一个ext3文件系统的大小为2.7 TB,fsck无法对其进行检查,因为它用尽了内存,并显示如下错误: 分配目录块数组时出错:内存分配失败 e2fsck:已中止 我添加了一个4 GB的交换分区,它仍然没有完成,但是这是一个32位内核,因此我不希望添加更多的分区会有所帮助。 除了启动到64位内核外,还有其他方法可以使fsck完成其检查吗?
13 linux  debian  memory  ext3  fsck 

4
Rsync -avzHP遵循硬链接,而不是将其复制为硬链接
我使用rsnapshot为我的“工作”共享创建每小时/每天/每周/每月的备份。现在,我尝试使用rsync将整个备份目录复制到外部驱动器上。 我在屏幕会话中使用了此命令/参数(是的,rsync-exclude.txt位于运行命令的目录中) rsync -avzHP --exclude-from 'rsync-exclude.txt' /share/backup/ /share/eSATADisk1/backup/; 整个程序都在QNAP TS-439上运行,内部驱动器是单个磁盘(无RAID)格式的EXT4,外部驱动器是EXT3格式。 发生的是:Rsync会跟踪每个硬链接并复制实际文件,而不是在外部驱动器上重新创建更新的硬链接。我不立即意识到这一点,因此外置驱动器最终被同一文件的xxx副本破坏了。 我要实现的是:将rsnapshot生成的整个文件结构复制到外部驱动器,同时保留硬链接以节省空间。注意:这不一定必须使用rsync完成。 感谢您的想法和时间。多谢您的帮助,辛苦了。 更新:我了解到,rsnapshot没有使用符号链接,而是在使用硬链接,所以我现在使用-H选项,该选项应将Rsnapshot的硬链接结构保留到多个目标位置(或维护硬链接结构),但仍然无法正常工作...我在这里想念什么? 更新2:我在这里找到了关于此主题的另一种意见/陈述:rsync与--hard-links冻结了 Steven Monday建议不要尝试rsync包含硬链接的大文件结构,因为它会占用大量内存,这对于rsync是一项艰巨的任务。因此,可能更好的解决方案是将我要备份的数据结构制成.img。你怎么看?

4
我应该使用哪种Windows ext3驱动程序?[关闭]
关闭。这个问题是题外话。它当前不接受答案。 6年前关闭。 已锁定。该问题及其答案被锁定,因为该问题是题外话,但具有历史意义。它目前不接受新的答案或互动。 我了解在Windows中有多种使用/访问ext2 / ext3的替代方法,例如HOWTO Forge文章和一年前另一篇文章中介绍的替代方法。但是,没有列出的项目提供对完全实现的ext3的完全读写访问权限。也就是说,这两个读写选项似乎不支持ext3日志。(ext2fsd将重播一个非空的日志,但看起来好像不使用它。否则,ext2fs.sys似乎根本不使用该日志。) 是否有人知道我可以在Windows中安装的驱动程序,以提供对ext3分区的完全读写访问权限,包括日志,用户权限,selinux属性(如果可能,至少保留它们)和其他扩展属性? 你们中的任何人实际使用过其中一种驱动程序吗?目前,我通过FAT32分区在双引导系统上的操作系统之间共享数据。我知道我可以使用NTFS,它在Linux下具有读写访问权限。但是,如果可能的话,我宁愿使用ext3。

6
如何在ext3 / 4上获得透明,高效的文件系统快照或版本控制?
我一直在考虑文件系统的版本控制。这是一个杀手级功能,我研究了Wayback,ext3cow,zfs,fuse解决方案,或者只是cvs / svn / git叠加层。 我认为ext3cow是符合我要求的模型。透明,高效,但是我可以不用其他ls abc@timestamp功能。只要我能以某种方式获得文件的自动化透明版本。 它可以是瞬时的,也可以基于10s,30s,1m,5m,15m等间隔的快照。这可以有效地处理给定目录中的数千个文件,这些文件大小各异,大多数很小,但有些超过100m至1gb。 ZFS并不是真正的选择,因为我在Linux上(并且不希望通过保险丝使用它,因为我已经拥有要版本化的ext3设置,而不是新的东西)。 有什么解决方案?

10
子目录的数量如何影响Linux上的读写性能?
我在Linux CentOS服务器上有一个EXT3格式化的驱动器。这是一个Web应用程序数据驱动器,其中包含每个用户帐户(有25,000个用户)的目录。每个文件夹都包含该用户已上传的文件。总体而言,该驱动器上大约有250GB的数据。 用所有这些目录构造驱动器是否会影响驱动器的读写性能?它会影响我不了解的其他性能方面吗? 以这种方式构造事物有天生的错误或坏处吗?也许只是错误选择文件系统? 我最近尝试合并两个数据驱动器,并意识到EXT3限于32,000个子目录。这让我想知道为什么。考虑到每个文件都有一个唯一的ID(对应于数据库中的ID),我以这种方式构建它似乎很愚蠢。las ...


2
调整lvm2逻辑卷和文件系统的大小:确切大小?
在我的Intranet服务器上,我有一个100.00 GiB分区/ dev / sda5,用作lvm2的物理卷。 这是我的卷组vg01中唯一的物理卷。 vg01当前包含一个逻辑卷lv01,使用完整的100.00 GiB-好吧,由于一些舍入,实际上是99.99 GiB(这就是问题开始的地方)。 lv01包含一个使用整个空间的ext3文件系统。 我想将lv01减少到大约97 GiB,所以我可以用lv01创建lv02。3 GiB(我需要它来拍摄lvm快照)。 到目前为止,我做了什么: e2fsck -f /dev/mapper/vg01-lv01 resize2fs /dev/mapper/vg01-lv01 97G 效果很好。但是现在我必须跑步 lvreduce --size ? /dev/mapper/vg01-lv01 而且我不确定,我必须指定哪个确切值。该lvreduce手册页明确警告说,所产生的大小不能大于文件系统更小。我也不想使它超出必须的大小。但是现在我有不同的数字: 我97G在resize2fs中指定。 df -h 说是96G。 df 说,这是100115936 1K块。 lvdisplay(当然)仍然报告逻辑卷的99.99 GiB。 我要指定lvreduce什么? 编辑: 当前接受的答案提供了一个不错的解决方法。但是,为了将这些内容集成到实体脚本等中,我通常更喜欢使用精确的度量。还是已经有一个可靠的(!)脚本或工具可以一步完成整个调整大小的过程?
10 lvm  ext3 

3
DL380 G5,RAID5,ext3,RAID失败
我们有一台旧的HP DL380G5服务器,在外部托架中的RAID5阵列中有5个300GB SCSI 3.5英寸磁盘,使用ext3文件系统格式化为逻辑卷,可容纳1.2 TB的敏感临床患者数据。 两张磁盘显示hpacucli发生预测性故障,因此我首先更换了其中一张,并确定可以,但是我没有看到它也显示“准备重建”。我也完全不小心更改了第二个,现在它说RAID已失败。 我退回了旧磁盘,尝试重新启动服务器,但是现在它在引导过程中使我进入恢复模式,并说找不到逻辑卷。 我可以做些什么来尝试恢复此状态?不幸的是,我们没有备份。任何帮助将不胜感激! 我当时正在考虑将两个旧驱动器都退还,是否有可能恢复RAID?
9 raid5  ext3 


4
ext3 fsck时间与分区大小
我正在为大型存储服务器场进行设置,为了避免使用长达一个月的fscks,我的计划是将存储分为多个较小的文件系统(这很好,因为我有一个结构良好的文件树,所以可容易地具有单独的文件系统安装在1/,2/,3/,4/,等等)。 我的困难是找到文件系统的“合理”大小的任何枚举,以使fsck时间同样“合理”。尽管我完全知道给定大小的绝对时间将在很大程度上取决于硬件,但是对于文件系统大小不同的ext3 fsck时间,我似乎找不到任何关于曲线形状的描述,以及其他变量是什么(在一个树中成千上万个目录中,一个文件目录中包含文件的文件系统所花的时间要长于一个文件系统所花费的时间;一个大文件与小文件;完整文件系统与空文件系统等等)。 有人引用过对此进行深入研究的数字吗?否则,有关这些问题的轶事至少应有助于指导我自己的实验。 编辑:澄清:无论文件系统如何,如果元数据出问题,都需要检查。是否启用或需要基于时间或基于挂载的重新fscks并不成问题,而我要求提供专门针对ext3的编号的唯一原因是因为这是最有可能选择的文件系统。如果您知道文件系统具有特别快的fsck进程,我欢迎您提出建议,但是它确实是一个可靠的选择(声称“文件系统X永远不需要fscking!”会被嘲笑并嘲笑其长度) 。我也意识到需要备份,并且对fsck的渴望并不能替代备份,但是当它出现故障时,只是丢弃文件系统并从备份中恢复,而不是fscking似乎是真的,
9 ext3  fsck 

5
内核:日记提交I / O错误
我在使用Dell 1950服务器时遇到了一些问题。我将在此处与Oracle和其他一些软件一起安装RHEL 4.6。 我在ssh会话和监视器上随机收到一条错误消息,内容为“内核:日记提交I / O错误”,我已连接到服务器,然后滚动查看错误消息,显示“ EXT3-fs错误(设备sda5)”在start_transaction中:日志已中止。” 它已经发生过几次,但从未在安装过程中的同一时间发生过。实际上,上一次系统启动并运行时,我只是试图将数据库导入到oracle中。 这已经发生在几个硬盘驱动器上,所以我很确定这不是问题。这使我认为RAI​​D控制器变坏了。 你们有什么感想? **更新** 可以肯定这是一个坏硬盘。我在服务器中扔了另一个驱动器,它已经运行了约48个小时,没有出现问题。
9 linux  raid  ext3 

1
Ext3文件名是否限制为255个符号或255个字节?
我无法在Ext3文件系统上保存名称超过127个西里尔UTF-8符号的文件。可以这样保存,但最多包含255个英语UTF-8符号。 那么包含文件名的字节数或文件名中的字符数是否有限制?例如,对于前者,可能希望对中文的文件名长度有更严格的限制。那正确吗?
9 ext3  utf-8 

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.