common/xfs: fix _xfs_get_file_block_size when rtinherit is set and no rt section

It's possible for the sysadmin to set rtinherit on the directory tree
even if there isn't a realtime section attached to the filesystem.  When
this is the case, the realtime flag is /not/ passed to new files, and
file data is written to the data device.  The file allocation unit for
the file is the fs blocksize, and it is not correct to use the rt
extent.

fstests can be fooled into doing the incorrect thing if test runner puts
'-d rtinherit=1 -r extsize=28k' into MKFS_OPTIONS without configuring a
realtime device.  This causes many tests to do the wrong thing because
they think they must operate on units of 28k (and not 4k).  Fix this.

Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>

diff --git a/common/xfs b/common/xfs
index 2c903d71c9170b698d29d34987d45122b599e838..93260fdb4599e2e0f7aae6273f3e00adabc0d216 100644 (file)
--- a/common/xfs
+++ b/common/xfs
@@ -213,6 +213,8 @@ _xfs_get_file_block_size()
 {
        local path="$1"
 
+       # If rtinherit or realtime are not set on the path, then all files
+       # will be created on the data device.
        if ! ($XFS_IO_PROG -c "stat -v" "$path" 2>&1 | grep -E -q '(rt-inherit|realtime)'); then
                _get_block_size "$path"
                return
@@ -223,6 +225,15 @@ _xfs_get_file_block_size()
        while ! $XFS_INFO_PROG "$path" &>/dev/null && [ "$path" != "/" ]; do
                path="$(dirname "$path")"
        done
+
+       # If there's no realtime section, the rtinherit and rextsize settings
+       # are irrelevant -- all files are created on the data device.
+       if $XFS_INFO_PROG "$path" | grep -q 'realtime =none'; then
+               _get_block_size "$path"
+               return
+       fi
+
+       # Otherwise, report the rt extent size.
        _xfs_get_rtextsize "$path"
 }