Shulou(Shulou.com)06/01 Report--

Centos6 how to build a XFS file system, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can get something.

XFS, a high-performance journaling file system, was first developed by Silicon Graphics for their IRIX operating system in 1993 and is the default file system for IRIX version 5.3. It was later transplanted to the Linux kernel. XFS is particularly good at handling large files while providing smooth data transfer. Format operations in a large storage environment, the speed of XFS file system is much faster than ext3, ext4 file system! And it is said that XFS can support up to 100T, and the read and write speed is better than that of other file systems.

System environment: CENTOS6.4

1. Install the xfs file system

The rpm packages needed by XFS can be found in the ISO file of the system. We only need to install xfsprogs and xfsdump packages.

[root@localhost Packages] # find. -name "xfs*.rpm"

. / xfsdump-3.0.4-3.el6.x86_64.rpm

. / xfsprogs-devel-3.1.1-10.el6.x86_64.rpm

. / xfsprogs-qa-devel-3.1.1-10.el6.i686.rpm

. / xfsprogs-qa-devel-3.1.1-10.el6.x86_64.rpm

. / xfsprogs-devel-3.1.1-10.el6.i686.rpm

. / xfsprogs-3.1.1-10.el6.i686.rpm

. / xfsprogs-3.1.1-10.el6.x86_64.rpm

[root@localhost Packages] # rpm-ivh xfsprogs-3.1.1-10.el6.x86_64.rpm xfsdump-3.0.4-3.el6.x86_64.rpm

Warning: xfsprogs-3.1.1-10.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY

Preparing... # [100%]

1:xfsprogs # # [50%]

2:xfsdump # # [100%]

II. XFS format

XFS formatting is so fast that it is done almost immediately.

[root@localhost Packages] # mkfs.xfs / dev/sdb

Meta-data=/dev/sdb isize=256 agcount=4, agsize=655360 blks

= sectsz=512 attr=2, projid32bit=0

Data = bsize=4096 blocks=2621440, imaxpct=25

= sunit=0 swidth=0 blks

Naming = version 2 bsize=4096 ascii-ci=0

Log = internal log bsize=4096 blocks=2560, version=2

= sectsz=512 sunit=0 blks, lazy-count=1

Realtime = none extsz=4096 blocks=0, rtextents=0

3. Mounting test

[root@localhost /] # mount-t xfs / dev/sdb / data

[root@localhost /] # mount | grep data

/ dev/sdb on / data type xfs (rw)

Test:

Write performance

[root@localhost test] # time dd if=/dev/zero of=/data/test/ceshi.txt bs=1M count=100

100 minutes 0 records in

100 minutes 0 records out

104857600 bytes (105 MB) copied, 0.42419 s, 247 MB/s

Real0m0.431s

User0m0.001s

Sys0m0.427s

Read performance

[root@localhost test] # time dd if=/data/test/ceshi.txt of=/dev/null bs=1M count=100

100 minutes 0 records in

100 minutes 0 records out

104857600 bytes (105 MB) copied, 0.129903 s, 807 MB/s

Real0m0.135s

User0m0.003s

Sys0m0.132s

IV. Supplementary XFS optimization

# mkfs.xfs-f-I size=512-l size=128m,lazy-count=1-d agcount=16 / dev/sdb1

-I size=512: the default value is 256KB. The setting here is for selinux. This setting is for Extend Attribute where inode size,selinux uses xfs. First, write it to inode. If the capacity is not enough (the default is 256KB, it is not enough, just a little more), then write it to block, which will lose performance when you need to use selinux. This does not seem to have any effect on ordinary users, because ordinary users do not use selinux, people still trust the security of the linux system, but, to be honest, I do not trust it, and RedHat's FC has been configured with selinux by default, which is good. With this change, it is convenient for me to configure selinux in the system without worrying about the loss of performance.

-l size=128m: note that it is lowercase m, not uppercase. The default is 10m (bsize=4096 x blocks=2560). This value can be set to 32m (partition capacity is not less than 250m) / 64m (partition capacity is not less than 500m) / 128m (partition capacity is not less than 700m). For the partition capacity limit, I only list here, the maximum can be set to 128m. Changing this parameter to 128m can significantly improve the speed of deleting files in the xfs file system, as well as others, such as copying files. This parameter needs to be supported by a large amount of memory, and machines with too little memory may not be able to set this high. What is the standard? 512M?1G? I don't understand, so I said above that I should actually test it myself. )

-l lazy-count=value

This changes the method of logging various persistent counters in the superblock. Under metadata intensive workloads, these counters are updated and logged frequently enough that the superblock updates become a serialisation point in the filesystem. The value can be either 0 or 1.

With lazy-count=1, the superblock is not modified or logged on every change of the persis-tent counters. Instead, enough information is kept in other parts of the filesystem to be able to maintain the persistent counter values without needed to keep them in the superblock. This gives significant improvements in performance on some configurations. The default value is 0 (off) so you must specify lazy-count=1 if you want to make use of this feature.

-d agcount=4: the default value is automatically set based on capacity. This parameter adjusts the occupancy rate of CPU. The smaller the value, the lower the occupancy rate. In theory, on my machine, agcount=1 has a higher cpu usage than agcount=2. I think this is because my cpu is dual-core. Note that the lower the occupancy rate of cpu, the lower the amount of data processed per second. I compared agcount=2 with 4 and found that 4 is better. In this way, the setting of this parameter needs to be chosen by yourself.

Xfs option of mount (key parameter nobarrier):

Vi / etc/fstab

Modify mount options

/ dev/sdb1 / data xfs defaults,noatime,nobarrier 00

Remount

Mount-o remount / data

Nobarrier

Many hardware RAID have a persistent write cache which preserves it across power failure, interface resets, system crashes, etc. Using write barriers in this instance is not recommended and will in fact lower performance. Therefore, it is recommended to turn off the barrier support and mount the filesystem with "nobarrier". But take care about the hard disk write cache, which should be off.

By default, noatime linux records the time of file access by atime, which is unnecessary in most cases. If you encounter a situation with high IO load or high CPU WAIT, you can try to use noatime, which is effective and effective.

Nobarrier mount

The XFS file system enables write barrier support by default when mounting. This feature flushes the write-back cache of subordinate storage devices at an appropriate time, especially when XFS is doing log writes. The original purpose of this feature is to ensure the consistency of the file system, but the implementation varies from device to device-not all subordinate hardware supports cache flushing requests. This feature can cause significant performance degradation when deploying XFS file systems on logical devices provided by hardware RAID controllers with battery-powered caches, because the code of the file system does not know that such caching is non-volatile. If the controller implements the flushing request again, the data will be written to the physical disk unnecessarily frequently. To prevent this problem, the XFS file system should be mounted with the nobarrier option for devices that can protect data in the cache in the event of a power outage or other host failure.

Logbufs=value

Set the number of in-memory log buffers. Valid numbers range from 2-8 inclusive. The default value is 8 buffers for filesystems with a blocksize of 64K, 4 buffers for filesystems with a blocksize of 32K, 3 buffers for filesystems with a blocksize of 16K, and 2 buffers for all other configurations. Increasing the number of buffers may increase performance on some workloads at the cost of the memory used for the additional log buffers and their associated control structures.

Logbsize=value

Set the size of each in-memory log buffer. Valid sizes are 16384 (16K) and 32768 (32K). The default value for machines with more than 32MB of memory is 32768, machines with less memory use 16384 by default.

After the test, it is found that the read and write performance can be better, and the test method is the same as above.

Fifth, the advantages and disadvantages of XFS

Advantages:

1. Data can be recovered.

With the XFS file system, when an unexpected downtime occurs, first of all, because the file system enables logging, the files on your disk will no longer be destroyed by accidental downtime. No matter how many files and data are stored on the current file system, the file system can quickly recover the contents of disk files in a very short time according to the recorded logs.

2. Fast transmission

The XFS file system uses an optimization algorithm, and logging has little impact on the overall file operation. XFS queries and allocates storage space very quickly. The xfs file system provides continuous fast response time. The author has tested the XFS, JFS, Ext3 and ReiserFS file systems, and the performance of the XFS file system is quite outstanding.

3. The file system is extensible.

XFS is a 64-bit file system that supports millions of terabytes of storage. Support for both large and small files is outstanding, supporting a large number of directories. The maximum supported file size is 263 = 9 x 1018 = 9 exabytes and the maximum file system size is 18 exabytes.

XFS uses a high table structure (B+ tree), which ensures that the file system can quickly search and allocate space quickly. XFS can continuously provide high-speed operation, and the performance of the file system is not limited by the number of directories and files in the directory.

Note: generally, partitions larger than 2T are divided by PARTED, while partitions larger than 16T can be divided by PARTED, but it is also easy to make mistakes when using EXT4 partition format to mount. At this time, it is normal to format a single partition larger than 16T with XFS, and then mount it.

4. Ibank 0 reads and writes quickly

XFS can store data at a performance similar to that of the bare device Ibank O. In the test of a single file system, its throughput can reach up to 7GB per second, and the throughput of read and write operations to a single file can reach 4GB per second.

Disadvantages:

The XFS file system cannot be shrunk.

Historically, metadata operations on XFS have been slower than other file systems, showing poor performance when deleting a large number of small files. This performance issue is identified in the code by Red Hat's XFS developer Dave Chinner. Using a mount option called "deferred logging" can improve the performance of metadata operations by orders of magnitude. This option stores almost the entire log in memory. The Linux kernel mainline version 2.6.35 introduced this patch as an experimental feature, made it a stable feature in 2.6.37, and plans to use it as the default logging method in 2.6.39. Early tests showed that its performance was close to EXT4 in an environment with a small number of threads and better than EXT4 in an environment with a large number of threads.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.