在尝试这个之前应该多读些关于这方面的知识，但是现在我知道得更多了…把事情搞砸了。 事后才知道xfs的缺点。 操作系统显然是安装了默认的分区和types，所以有以下几点： /dev/mapper/cl-root 50G xfs /dev/mapper/cl-home 50G xfs cl-root已经达到了100％，所以我以为自己并没有真正被使用，所以我会从cl-home那里窃取这个空间。 有以下几点： lvresize –size 10GB /dev/mapper/cl-home lvresize –size 89GB /dev/mapper/cl-root 两个都是成功的，这些变化反映在每个卷的lvdisplay中; 然而df -h仍然显示他们是相同的大小。 决定重新启动，这是由于/home没有正确安装而进入紧急模式的地方。 作为一个解决办法，我修改了/etc/fstab ，这样nofail可以启动/dev/mapper/cl-home ，这样可以正常启动，尽pipe它重做了/home目录。 我看着df -h ，它没有显示/dev/mapper/cl-home ，文件系统仍然显示/dev/mapper/cl-root相同的大小。 lvdisplay显示调整驱动器大小。 尝试mount /home并获得： mount: /dev/mapper/cl-home: can't read superblock 。 据我所知，减小或增加文件系统大小的过程分为两部分：1）修改逻辑卷，然后2）修改文件系统。 我已经做了1）的印象，只需要做2）。 尝试： resize2fs /dev/mapper/cl-home 10G resize2fs 1.42.9 (28-Dec-2013) resize2fs: Bad magic number in super-block while […]
昨天我们在Centos 7.4虚拟机中尝试了yum更新，正如我们之前所做的那样，使用qcow2快照，使用主映像作为后备存储，如本教程中所述： http://dustymabe.com/2015/01/11/qemu-img-backing-files-a-poor-mans-snapshotrollback/ 然而，毕竟看起来不错，我closures了虚拟机，将SNAP提交到主映像，并将虚拟机修改为再次指向主存储。 引导出惊喜之后，不再启动，经过几个小时的debugging，我们的团队就能指出XFS文件系统已经损坏，并尝试用xfs_repair修复它。 pipe理修复它，但现在我们有几个问题与破包（我们将能够修复RPM / YUM）。 将这些快照提交到源qcow2图像不安全吗？ 过去我们已经做到了这一点，过去一直没有问题。 我没有意识到我们可能因此而出现任何问题。 迄今为止这样做了几次。 这是否可以实现，我们有一个比在Gues操作系统上的KVMpipe理程序更旧的Centos？ KVM有Centos 7.2，而VM有Centos 7.4，都使用XFS文件系统。 请指教。 过去有没有人有这个问题？
我在一个amd x4,4gb ram，2x seagate sata 1 tb磁盘上安装了一个ubuntu（服务器内核），用于testing虚拟机，写入性能非常慢。 这两个磁盘在一个软件raid1arrays，一个小引导ext3分区，10GB系统分区，其余的是一个xfs分区（约980）gb的数据（虚拟机）。 如果我使用rsync或scp将文件从虚拟机复制到主机，复制频繁停顿或以大约1mb / s的速度运行。 怎么了？ 我已经尝试禁用xfs的障碍，增加了logbufs，allocsize，但似乎没有什么帮助。 奇怪的是，等待（例如在复制过程中）sda通常在100以下，而sdb则在400左右。 任何想法可能是错误的/我能做些什么来改善这个设置？
我在SLES 10.2服务器上有一个10TB的XFS文件系统。 我目前每天运行一次rsync ，将其与另一台服务器上基于磁盘的联机备份进行同步。 主卷相当繁忙，所以rsync平均只能以2MB /秒的速度运行。 但是，我可以scp文件并获得> 50MB /秒的相同的目的地。 这导致我相信，rsync负担过重， 决定转移什么 ，而不是实际转移 。 还有哪些其他方法可以实现这种types的合成完全备份？ 以下观点的相对利弊是什么？ 使用xfsdump ，通过ssh或类似的方式传送到xfsrestore上的xfsrestore 。 它能用这种方式进行增量吗？ 一些使用drbd或类似的asynchronous块复制。 一些更好的使用rsync比如更宽松的比较标准。 我目前正在使用 rsync -aqAX –numeric-ids –delete-during –files-from=foo …
我在一个RAID10 linux软arrays中有一个带有12个1T驱动器的NAS服务器。 主要的数据区域是一个5.4TB的XFS分区。 在该分区上，我一直在创buildiSCSI磁盘映像，利用XFS“精简configuration”空间的function。 这意味着分配更多的磁盘比你立即要使用（即超出磁盘）。 我目前已经分配了大约15TB，但实际上只使用了大约4.5TB。 我需要为这个分区设置一个备份，但是我不想创build一个15 + TB的数组来保存它，如果我直接复制磁盘映像的话，我需要这个数组。 我的问题是：1）如何复制该分区而不需要全部分配的空间。 LVM快照会处理这个问题吗？ 2）有没有办法做增量备份（备份每晚都会发生，而且我不希望每晚都有一个多TB传输窒息我的networking）。 这是我的音量/分区configuration，如果有帮助： vgdisplay dedvol — Volume group — VG Name dedvol System ID Format lvm2 Metadata Areas 5 Metadata Sequence No 10 VG Access read/write VG Status resizable MAX LV 0 Cur LV 1 Open LV 1 Max PV 0 Cur PV 5 Act […]
我有一个数据库备份脚本，它执行一个mysqldump并将转储复制到一个带有XFS分区的外部硬盘上。 不幸的是，在复制过程中，驱动器卸载，设备从/ dev / sdc改为/ dev / sdd。 / dev / sdc1仍将被挂载，但挂载的文件夹不可访问。 我卸载驱动器，那是/ dev / sdd（或者它决定的驱动器）出现的时间。 我装载，它工作得很好。 备份脚本运行时的dmesg输出如下所示： [328722.136119] usb 2-1: USB disconnect, address 69 [328722.172828] xfs_force_shutdown(sdc1,0x1) called from line 335 of file /build/buildd/linux-2.6.32/fs/xfs/xfs_rw.c. Return address = 0xffffffffa030f9d3 [328722.172845] Filesystem "sdc1": I/O Error Detected. Shutting down filesystem: sdc1 [328722.181694] Please umount the filesystem, and rectify […]
EXT3支持32,000个子目录。 EXT4支持64,000 … 我已经阅读了XFS文件系统上拥有数百万个子目录的人，但无法find任何地方引用的确切值。 XFS文件系统支持多less个子目录？
对于可以在XFS文件系统中设置的最大元数据日志大小，我有点困惑。 我在任何地方都能find相同的信息：最大尺寸为64K块或128M，以较小者为准。 对于标准的4K块大小，我有最大的元数据logsize = min（256M，128M）= 128M。 公平的，但是当我试图创build一个大于128M的元数据日志的文件系统，我没有得到任何的错误，这是由xfs_info命令的输出确认的： ingrid:/home/engineer # mkfs.xfs -f -l size=1024m /dev/md0 meta-data=/dev/md0 isize=256 agcount=16, agsize=2359280 blks = sectsz=512 attr=2 data = bsize=4096 blocks=37748480, imaxpct=25 = sunit=16 swidth=64 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal log bsize=4096 blocks=262144, version=2 = sectsz=512 sunit=16 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 内部日志的版本2中是否有任何新function可以覆盖128M限制？ ingrid:/home/engineer # […]
我找不到在我的一个磁盘上创build文件系统的方法。 首先我geting下面的输出： [root@~]# mkfs.xfs /dev/sdb1 mkfs.xfs: /dev/sdb1 appears to contain a partition table (dos). mkfs.xfs: Use the -f option to force overwrite. 使用-F标志后： [root@~]# mkfs.xfs -f /dev/sdb1 meta-data=/dev/sdb1 isize=256 agcount=32, agsize=22892696 blks = sectsz=512 attr=2 data = bsize=4096 blocks=732566272, imaxpct=5 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal log bsize=4096 blocks=357698, version=2 […]
我有许多XFS驱动器上的xattr小文件（2千万）。 文件的平均大小约为20KB，xattr的平均大小约为512字节。 因为我想将它们移动到ext4，我testing了将这些文件的一部分复制到ext4（inode大小为512和1024）和XFS驱动器。 我分别用以下选项格式化了3个驱动器： # mkfs.ext4 -i 8192 -I 512 /dev/sde1 # mkfs.ext4 -i 8192 -I 1024 /dev/sdf1 # mkfs.xfs -f -i size=1024 /dev/sdg1 并通过cp -r –preserve = mode，所有权，时间戳，xattr复制大约30GB的小文件 结果如下： Filesystem 1K-blocks Used Available Use% Mounted on /dev/sde1 133654640 37164884 89360916 30% /srv/node/sde1 # ext4 -I 512 /dev/sdf1 124741744 36645652 80967252 32% /srv/node/sdf1 # ext4 […]