xfs

The following are known xfs issues:

File system corruption occurs after direct I/O writes

A race condition that results in post-eof blocks being used for direct I/O writes causes a corruption in the file system. If a file release occurs during a file extending direct I/O write, it is possible to mistake the post-eof blocks for speculative preallocation and incorrectly truncate them from the inode. This issue is unlikely to be reproduced in real-world workloads. (Bug ID 26128822)

Invalid corrupted file system error resulting from a problem with log recovery on v5 superblocks

A problem with log recovery on v5 superblocks that causes the metadata LSN not to update for buffers that it writes out, can result in a corruption error similar to the following:

[1044224.901444] XFS (sdc1): Metadata corruption detected at
xfs_dir3_block_write_verify+0xfd/0x110 [xfs], block 0x1004e90
[1044224.901446] XFS (sdc1): Unmount and run xfs_repair
...
[1044224.901460] XFS (sdc1): xfs_do_force_shutdown(0x8) called from line 1249
of file fs/xfs/xfs_buf.c.  Return address = 0xffffffffa07a8910
[1044224.901462] XFS (sdc1): Corruption of in-memory data detected.  Shutting
down filesystem
[1044224.901463] XFS (sdc1): Please umount the filesystem and rectify the
problem(s)
[1044224.904207] XFS (sdc1): log mount/recovery failed: error -117
[1044224.904456] XFS (sdc1): log mount failed"

This problem is encountered because the log attempts to replay a buffer update that is no longer valid due to subsequent replayed updates. The result is a corruption error, when in fact, the file system is fine. (Bug ID 25380003)

System hangs on unmount after a buffered append to a file with negative i_size

While it is invalid for a file system to load an inode with a negative i_size, it is possible to create a file like this, and in the case where a buffer appends to it, an integer overflow in the routine's underlying writeback results in the kernel locking up. A direct append does not cause this behavior. (Bug ID 25565490)
System hangs during xfs_fsr on two-extent files with speculative preallocation

During an xfs_fsr process on extents that are generated by speculative preallocation, the code that determines whether all of the extents fit inline miscalculates because the di_nextents call that is used does not account for these extents. This results in corruption of the in-memory inode, and ultimately the code attempts to move memory structures using incorrectly calculated ranges. This causes a kernel panic. (Bug ID 25333211)
XFS quotas are disabled after a read-only remount on Oracle Linux 6

Quotas are disabled on XFS if the file system is remounted with read-only permissions on Oracle Linux 6. (Bug ID 22908906)
Overlay file system is unable to mount on XFS where there is no d_type support

Overlay file systems rely on a feature known as d_type support. This feature is a field within a data structure that provides some metadata about files in a directory entry within the base file system. Overlay file systems use this field to track many file operations such as file ownership changes and whiteouts. d_type support can be enabled in XFS when the file system is created, by using the -n ftype=1 option. When d_type support is not enabled, an overlay file system might become corrupt and behave in unexpected ways. For this reason, this update release of UEK R4 prevents the mounting of an overlay file system on an XFS base, where d_type support is not enabled.

The root partition on Oracle Linux is automatically formatted with -n ftype=0, where XFS is selected as the file system. Thus, for backward compatibility reasons, if you have overlay file systems in place already and these are not hosted on alternate storage, you must migrate them to a file system that is formatted with d_type support enabled.

To check that the XFS file system is formatted correctly:
```
# xfs_info /dev/sdb1 |grep ftype
```
Replace /dev/sdb1 with the path to the correct storage device. If the information returned by this command includes ftype=0, you must migrate the overlay data held in this directory to storage that is formatted correctly.

To correctly format a new block device with the XFS file system with support for overlay file systems, do:
```
# mkfs -t xfs -n ftype=1 /dev/sdb1
```
Replace /dev/sdb1 with the path to the correct storage device. It is essential that you use the -n ftype=1 option when you create the file system.

If you do not have additional block storage available, it is possible to create an XFS file system image and loopback that can be mounted. For example, to create a 5 GB image file in the root directory, you could use the following command:
```
# mkfs.xfs -d file=1,name=/OverlayStorage,size=5g -n ftype=1
```
To temporarily mount this file, you can enter:
```
# mount -o loop -t xfs /OverlayStorage /mnt
```
Adding an entry in /etc/fstab to make a permanent mount for this storage, might look similar to the following:
```
/OverlayStorage    /mnt        xfs     loop            0 0 
```
This configuration can help as a temporary solution to solve upgrade issues. However, using a loopback mounted file system image as a form of permanent storage is not recommended for production environments. (Bug ID 26165630)