]> git.ipfire.org Git - thirdparty/xfsprogs-dev.git/log
thirdparty/xfsprogs-dev.git
9 years agolibxlog: add xlog_is_empty() helper
Eric Sandeen [Tue, 28 Jul 2015 23:04:35 +0000 (09:04 +1000)] 
libxlog: add xlog_is_empty() helper

xfs_repair and xfs_db both check for a dirty log, using roughly
the same cut and pasted code.

Add a new helper to do this, xlog_is_dirty(), and use it instead.

Note, the helper (and the code before it) is a little odd in that
it (re-)initializes some libxfs_init_t members before proceeding,
I haven't yet worked out if that's necessary or correct, so I've
just kept the same behavior for now.  Still, it seems like this
should be done in libxfs_init, or not at all.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfsprogs: v3.2.3 release v3.2.3
Dave Chinner [Wed, 10 Jun 2015 00:12:00 +0000 (10:12 +1000)] 
xfsprogs: v3.2.3 release

Update changelog and version files for upcoming release.

Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfsprogs: update deb packaging for upcoming release
Nathan Scott [Wed, 10 Jun 2015 00:09:36 +0000 (10:09 +1000)] 
xfsprogs: update deb packaging for upcoming release

Update debian changelog file for upcoming release.

Signed-off-by: Nathan Scott <nathans@debian.org>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfsprogs: update for 3.2.3-rc2 release v3.2.3-rc2
Dave Chinner [Mon, 1 Jun 2015 01:17:41 +0000 (11:17 +1000)] 
xfsprogs: update for 3.2.3-rc2 release

Update changelog and version files for upcoming release.

Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_repair: ensure .. is set sanely when rebuilding dir
Darrick J. Wong [Mon, 1 Jun 2015 01:17:39 +0000 (11:17 +1000)] 
xfs_repair: ensure .. is set sanely when rebuilding dir

When we're rebuilding a directory, ensure that we reinitialize the
directory with a sane parent ('..') inode value.  If we don't, the
error return from xfs_dir_init() is ignored, and the rebuild process
becomes confused and leaves the directory corrupt.  If repair later
discovers that the rebuilt directory is an orphan, it'll try to attach
it to lost+found and abort on the corrupted directory.  Also fix
ignoring the return value of xfs_dir_init().

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_repair: better checking of v5 metadata fields
Darrick J. Wong [Mon, 1 Jun 2015 01:17:09 +0000 (11:17 +1000)] 
xfs_repair: better checking of v5 metadata fields

Check the UUID, owner, and block number fields during repair, looking for
blocks that fail either the checksum or the data structure verifiers.  For
directories we can simply rebuild corrupt/broken index data, though for
anything else we have to toss out the broken object.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_repair: validate superblock against known v5 feature flags
Darrick J. Wong [Mon, 1 Jun 2015 01:17:08 +0000 (11:17 +1000)] 
xfs_repair: validate superblock against known v5 feature flags

Apparently xfs_repair running on a v5 filesystem doesn't check the
compat, rocompat, or incompat feature flags for bits that it doesn't
know about, which means that old xfs_repairs can wreak havoc.  So,
strengthen the checks to prevent repair from "repairing" anything it
doesn't understand.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Fanael Linithien <fanael4@gmail.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_repair: properly detect reserved attribute names
Eric Sandeen [Tue, 26 May 2015 22:43:02 +0000 (08:43 +1000)] 
xfs_repair: properly detect reserved attribute names

This function in xfs_repair tries to make sure that if an attr
name reserved for acls exists in the root namespace, then its
value is a valid acl.

However, because it only compares up to the length of the
reserved name, superstrings may match and cause false positive
xfs_repair errors.

Ensure that both the length and the content match before
flagging it as an error.

Spotted-by: Zach Brown <zab@zabbo.net>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfsprogs: update for 3.2.3-rc1 release v3.2.3-rc1
Dave Chinner [Mon, 11 May 2015 00:46:06 +0000 (10:46 +1000)] 
xfsprogs: update for 3.2.3-rc1 release

Update changelog and version files for upcoming release.

Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agomkfs: inode/block size error messages confusing
Dave Chinner [Mon, 11 May 2015 00:09:22 +0000 (10:09 +1000)] 
mkfs: inode/block size error messages confusing

As reported by Brain:

# ./mkfs/mkfs.xfs -f /dev/test/scratch -b size=512
illegal inode size 512
allowable inode size with 512 byte blocks is 256
# ./mkfs/mkfs.xfs -f /dev/test/scratch -b size=512 -i size=256
Minimum inode size for CRCs is 512 bytes
Usage: mkfs.xfs
...

Fix mkfs to catch the block size as being too small, rather than
leaving it for inode size detection to enforce.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agomkfs: default to CRC enabled filesystems
Dave Chinner [Mon, 11 May 2015 00:09:19 +0000 (10:09 +1000)] 
mkfs: default to CRC enabled filesystems

It's time to change the mkfs defaults to enable CRCs for all new
filesystems. While there, also enable the free inode btree by
default, too, as that functionality has also had long enough to make
it into distro kernels, too. Also update the man page to reflect the
change in defaults.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_db: report FINOBT in version output
Eric Sandeen [Mon, 11 May 2015 00:09:18 +0000 (10:09 +1000)] 
xfs_db: report FINOBT in version output

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfsprogs: Removing deprecated _BSD_SOURCE definition.
Jan Ťulák [Mon, 11 May 2015 00:09:16 +0000 (10:09 +1000)] 
xfsprogs: Removing deprecated _BSD_SOURCE definition.

In glibc 2.20, _BSD_SOURCE was deprecated in favor of _DEFAULT_SOURCE.
_DEFAULT_SOURCE is included with _GNU_SOURCE, as well as _XOPEN_SOURCE >= 500,
so the obsolete and unnecessary definitions are removed.

For more details, see man 7 feature_test_macros for glibc >= 2.20.

Signed-off-by: Jan Ťulák <jtulak@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agolibhandle: add fd_to_handle to handle.h
Sage Weil [Sun, 12 Apr 2015 23:33:50 +0000 (09:33 +1000)] 
libhandle: add fd_to_handle to handle.h

It's on the man page but strangely missing from the header.

Signed-off-by: Sage Weil <sage@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfsprogs: remove unreachable code in libxfs_inode_alloc
Eric Sandeen [Sun, 12 Apr 2015 23:33:49 +0000 (09:33 +1000)] 
xfsprogs: remove unreachable code in libxfs_inode_alloc

This code does:

        if (!ialloc_context && !ip)
                return;

        // if !ip here, ialloc_context must be true

        if (ialloc_context) {
                ...
                if (!ip)
                        error = ENOSPC;
                if (error)
                        return error;
                // if !ip in this block we've returned
        }

        // so (!ip) cannot be true here
        if (!ip)
                error = ENOSPC;

(cherry picked this one out of Coverity reports)

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_db: disallow sb UUID write on v5 filesystems
Eric Sandeen [Sun, 12 Apr 2015 23:33:47 +0000 (09:33 +1000)] 
xfs_db: disallow sb UUID write on v5 filesystems

Do not allow xfs_db (or the xfs_admin frontend) to change the UUID
of a V5 filesystem; this will cause UUID mismatches across the
filesystem, and we currently have no mechanism to update them all.
Changing only the superblock UUID makes all other metadata look
invalid, and xfs_repair reacts by junking everything.

Addresses-Debian-Bug: 782012
Reported-by: F. Stoyan <fstoyan@swapon.de>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agorepair: only check secondary sb->sb_pquotino for v5 superblocks
Brian Foster [Sun, 12 Apr 2015 23:33:46 +0000 (09:33 +1000)] 
repair: only check secondary sb->sb_pquotino for v5 superblocks

xfs_repair scans for garbage data beyond the last valid superblock field
for the particular sb version in secondary_sb_wack(). If any non-zero
data is detected, the entire range is reset to zero. Subsequently,
various valid superblock fields are checked for valid/expected data.

The sb_pquotino field is checked unconditionally as part of this
sequence even though it is a v5 only field. As a result, repair
complains about a non-null project quota field if any garbage data
exists for a v4 secondary sb. This is reproduced by xfs/070 against a v4
superblock and is also easily reproduced manually as follows:

$ mkfs.xfs -f -m crc=0 <dev>
$ xfs_db -x -c "sb 3" -c "write lsn 1" <dev>
$ xfs_repair <dev>
...
zeroing unused portion of secondary superblock (AG #3)
non-null project quota inode field in superblock 3
...

This occurs because the garbage data detection mechanism has reset
sb->sb_pquotino to 0 while the validity check expects a value of
NULLFSINO.

Update secondary_sb_wack() to only check sb->sb_pquotino for validity on
supers where it is a valid field. If it is anything other than 0 on
pre-v5 superblocks, it is explicitly reset to 0 by the garbage data
checks earlier in the function.

Reported-by: Xing Gu <gux.fnst@cn.fujitsu.com>
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agodb/check: handle zero inoalignmt correctly for large block sizes
Brian Foster [Tue, 7 Apr 2015 00:04:11 +0000 (10:04 +1000)] 
db/check: handle zero inoalignmt correctly for large block sizes

The check command prints a spurious error when sb_inoalignmt is zero but
the sb align feature bit is set:

$ mkfs.xfs -f -bsize=16k <dev>
$ xfs_db -c "check" <dev>
sb versionnum extra align bit 80

This occurs because check determines whether to expect the alignment
feature bit based on a non-zero inoalignmt (in init()). sb_inoalignmt of
0 is expected for block sizes that are large enough for at least one
full inode record (64 inodes), however. For example, when bsize >= 16k
on v4 filesystems or >=32k on v5 filesystems.

Update the init() logic in the check command to detect this particular
scenario. Set the in-memory feature bit if inoalignmt is zero and the
block size is large enough for full inode records such that blockget_f()
does not complain.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agomkfs: don't zero old superblocks if file was truncated
Brian Foster [Tue, 7 Apr 2015 00:04:11 +0000 (10:04 +1000)] 
mkfs: don't zero old superblocks if file was truncated

If the force overwrite option is passed to mkfs, we attempt to zero old
superblock metadata on the mkfs target. We attempt to read the primary
superblock to identify the secondary superblocks.

If the mkfs target is a regular file, it is truncated on open and the
secondary superblock zeroing operation returns a spurious and incorrect
error message due to a 0-byte read:

$ mkfs.xfs -f -d file=1,name=xfs.fs,size=32m
...
existing superblock read failed: Inappropriate ioctl for device

Fix the error reporting in zero_old_xfs_structures() to only print an
error string if the pread() call returns an error. Warn the user if the
read doesn't match the sector size. Finally, detect the case where we
know we've already truncated a regular file and skip the sb zeroing.

Reported-by: Alexander Tsvetkov <alexander.tsvetkov@oracle.com>
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agolibxfs: don't write uninitialized heap contents into new directory blocks
Darrick J. Wong [Tue, 7 Apr 2015 00:04:11 +0000 (10:04 +1000)] 
libxfs: don't write uninitialized heap contents into new directory blocks

Clear the contents of the xfs buffer when we're initializing it to avoid
writing random heap contents (and CRC thereof) to disk.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_repair: don't abort on bad directory leaf crc during leaf check
Darrick J. Wong [Tue, 7 Apr 2015 00:04:11 +0000 (10:04 +1000)] 
xfs_repair: don't abort on bad directory leaf crc during leaf check

longform_dir2_check_leaf() checks a directory leaf block to help
decide if we need to rebuild the directory.  If the verifier fails
with a CRC or corrupt structure error, rebuild the directory instead
of aborting.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_repair: validate & fix inode CRCs
Eric Sandeen [Tue, 7 Apr 2015 00:04:11 +0000 (10:04 +1000)] 
xfs_repair: validate & fix inode CRCs

xfs_repair doesn't ever check an inode's CRC, so it never repairs
them.  If the root inode or realtime inodes have bad crcs, the
fs won't even mount and can't be fixed (without using xfs_db).

It's fairly straightforward to just test the inode CRC before
we do any other checking or modification of the inode, and
just mark it dirty if it's wrong and needs to be re-written.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_repair: don't clear . or .. in process_dir2_data
Eric Sandeen [Tue, 7 Apr 2015 00:04:11 +0000 (10:04 +1000)] 
xfs_repair: don't clear . or .. in process_dir2_data

process_dir2_data() has special . and .. processing; it is able
to correct these inodes, so there is no reason to clear them.

Do this before we adjust a length 0 filename to length 1, so
that we don't take this action on an accidentally created "."
name from a hidden dotfile.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_repair: set *parent if process_dir2_data() fixes root inode
Eric Sandeen [Tue, 7 Apr 2015 00:04:11 +0000 (10:04 +1000)] 
xfs_repair: set *parent if process_dir2_data() fixes root inode

process_dir2_data() may fix the root dir's parent inode:

"bad .. entry in root directory inode 6912, was 7159: correcting"

But we don't update the *parent passed in in that case; this then leads to
an assert later in process_dir2:

xfs_repair: dir2.c:2039: process_dir2:
  Assertion `(ino != mp->m_sb.sb_rootino && ino != *parent) ||
  (ino == mp->m_sb.sb_rootino && (ino == *parent || need_root_dotdot == 1))'
  failed.

Updating the value of *parent when we fix the parent value resolves this
problem.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_repair: clear need_root_dotdot if we rebuild the root dir
Eric Sandeen [Tue, 7 Apr 2015 00:04:11 +0000 (10:04 +1000)] 
xfs_repair: clear need_root_dotdot if we rebuild the root dir

It's possible to enter longform_dir2_rebuild with need_root_dotdot
set; rebuilding it will add "..", and if need_root_dotdot stays set,
we'll add another ".." entry, causing a second repair to find and
fix that problem.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agolibxfs: remove ASSERT on ftype read from disk
Eric Sandeen [Tue, 7 Apr 2015 00:04:08 +0000 (10:04 +1000)] 
libxfs: remove ASSERT on ftype read from disk

This one is already fixed in the kernel, with
fb04013 xfs: don't ASSERT on corrupt ftype
but that kernel<->userspace merge is still pending.

In the meantime, just fix it as a one-off here, because ASSERTing
on bad on-disk values when running xfs_repair is a very unfriendly
thing to do.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_repair: remove last-entry hack in process_sf_dir2
Eric Sandeen [Mon, 6 Apr 2015 23:20:15 +0000 (09:20 +1000)] 
xfs_repair: remove last-entry hack in process_sf_dir2

process_sf_dir2() tries to special-case the last entry in
a short form dir, and salvage it if the name length is wrong
by using the dir size as a clue to what the length should be.

However, this doesn't actually work; there is either a 32-bit
or 64-bit inode after the name, and with dirv3 there's a file
type in there as well.  Extending the name length to the dir
size means it overlaps these fields, which often have a 0 in
the top bits, and then namecheck() fails the result and junks
it anyway:

> entry #1 is zero length in shortform dir 67, resetting to 29
> entry contains illegal character in shortform dir 67
> junking entry "bbbbbbbbbbbbbbbbbbbbbbbb" in directory inode 67

And depending on the corruption, the current code will set
a new negative namelen if it turns out that the name itself
starts beyond dir size; it can't be shortened enough.

So, we could fix this up, and choose a new namelen such that
the xfs_dir2_ino8_t and/or xfs_dir2_ino8_t and/or file type
still fits at the end, but we really seem to be reaching the
point of diminishing returns.  The chances that nothing but
the name length is wrong, and that the remaining few
bytes at the end of the dir size are actually correct, seems
awfully small.

Therefore just remove this special case, which I think is
of questionable value.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_repair: collapse 2 cases in process_sf_dir2
Eric Sandeen [Mon, 6 Apr 2015 23:20:07 +0000 (09:20 +1000)] 
xfs_repair: collapse 2 cases in process_sf_dir2

process_sf_dir2() has 2 cases for a bad namelen: on-disk namelen
is 0, or on-disk namelen extends beyond the directory i_size.

After the prior 2 patches, the code for each case is now essentially
the same, so collapse the two cases.

Note, this does slightly change some of the error messages.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_repair: remove impossible tests in process_sf_dir2
Eric Sandeen [Mon, 6 Apr 2015 23:19:59 +0000 (09:19 +1000)] 
xfs_repair: remove impossible tests in process_sf_dir2

We're testing for an impossible case in here:

                if (i == num_entries - 1)  {
...
                } else  {
...
                                if (i == num_entries - 1)
                                    /* can't happen! */
...
                }

So, remove the impossible case.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_repair: dirty inode in process_sf_dir2 if we change namelen
Eric Sandeen [Mon, 6 Apr 2015 23:19:51 +0000 (09:19 +1000)] 
xfs_repair: dirty inode in process_sf_dir2 if we change namelen

There are two "fix sfep->namelen" cases, but we only mark
*dino_dirty = 1 in one of them.  Add the other to ensure that
the change gets written out.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_db: nlink fields are valid for di_version == 3, too
Eric Sandeen [Mon, 6 Apr 2015 23:19:41 +0000 (09:19 +1000)] 
xfs_db: nlink fields are valid for di_version == 3, too

Printing inodes with di_version == 3 skips the nlink
fields, because they are only printed if di_version == 2.
This was intended to separate them from di_version == 1,
but it mistakenly excluded di_version == 3, which also contains
these fields.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_db: fix inode CRC validity state, and warn on read if invalid
Eric Sandeen [Mon, 6 Apr 2015 23:19:28 +0000 (09:19 +1000)] 
xfs_db: fix inode CRC validity state, and warn on read if invalid

Currently, the "ino_crc_ok" field on the io cursor reflects
overall inode validity, not CRC correctness.  Because it is
only used when printing CRC validity, change it to reflect
only that state - and update it whenever we re-write the
inode (thus updating the CRC).

In addition, when reading an inode, warn if the CRC is bad.

Note, when specifying an inode which doesn't actually exist,
this will claim corruption; I'm not sure if that's good or
bad. Today, it already issues corruption errors on the way;
this adds a new message as well:

xfs_db> inode 129
Metadata corruption detected at block 0x80/0x2000
Metadata corruption detected at block 0x80/0x2000
...
Metadata CRC error detected for ino 129

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_db: Allow writes of corrupted data
Eric Sandeen [Mon, 6 Apr 2015 23:19:04 +0000 (09:19 +1000)] 
xfs_db: Allow writes of corrupted data

Being able to write corrupt data is handy if we wish to test
repair against specific types of corruptions.

Add a "-c" option to the write command which allows this by removing
the write verifier.

Note that this also skips CRC updates; it's not currently possible
to write invalid data with a valid CRC; CRC recalculation is
intertwined with validation.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agorepair: superblock buffers need to be sector sized
Dave Chinner [Wed, 18 Mar 2015 04:10:09 +0000 (15:10 +1100)] 
repair: superblock buffers need to be sector sized

In secondary_sb_wack() we zero the unused portion of both the
on-disk superblock and the in-memory copy that we have. When
the device sector size is 4k, this causes xfs_repair to crash like
so:

# xfs_repair /dev/ram1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
bad magic number
bad on-disk superblock 3 - bad magic number
primary/secondary superblock 3 conflict - AG superblock geometry info conflicts with filesystem geometry
zeroing unused portion of secondary superblock (AG #3)
#

The stack trace is indicative:

#0  memset ()
#1  0x000000000040404b in secondary_sb_wack
#2  verify_set_agheader
#3  0x0000000000427b4b in scan_ag
#4  0x000000000042a2ca in worker_thread
#5  0x00007ffff77ba0a4 in start_thread
#6  0x00007ffff74efc2d in clone

Which points at memset overrunning the in memory buffer, as it is
only 512 bytes in length.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agomkfs: log stripe unit fails to influence default log size
Dave Chinner [Tue, 24 Feb 2015 04:05:25 +0000 (15:05 +1100)] 
mkfs: log stripe unit fails to influence default log size

This fails on a 4GB, 4k physical sector size device:

# mkfs.xfs -f -l version=2,su=256k /dev/ram1
log size 2560 blocks too small, minimum size is 3264 blocks
....

The combination of 4k sectors and a log stripe unit increase the
minimum size of the log.  We should be automatically calculating an
appropriate, valid log size when the user does not specify it.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agometadump: check for non-zero inode alignment
Brian Foster [Tue, 24 Feb 2015 00:20:31 +0000 (11:20 +1100)] 
metadump: check for non-zero inode alignment

The copy_inode_chunk() function performs some basic sanity checks on the
inode record, block number, etc. One of these checks includes whether
the inode chunk is aligned according to sb_inoalignmt. sb_inoalignment
can equal 0 with larger block sizes. This results in a mod-by-zero,
"badly aligned inode ..." warnings and skipped inodes in metadump
images. This can be reproduced with a '-m crc=1,finobt=1 -b size=64k' fs
on ppc64.

Update copy_inode_chunk() to only enforce the inode alignment check when
sb_inoalignmt is non-zero.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agometadump: include NULLFSINO check in inode copy code
Brian Foster [Tue, 24 Feb 2015 00:19:31 +0000 (11:19 +1100)] 
metadump: include NULLFSINO check in inode copy code

The copy_ino() function includes a check for effectively NULL inode
numbers. It checks for 0 but does not include NULLFSINO. This leads to
spurious warnings in some instances. For example, copy_ino() is called
unconditionally for sb quota inodes from copy_sb_inodes(), values of
which can be NULLFSINO.

Check for NULLFSINO and return quietly from copy_ino().

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfsprog: xfsio: update xfs_io manpage for FALLOC_FL_INSERT_RANGE
Namjae Jeon [Tue, 24 Feb 2015 00:19:13 +0000 (11:19 +1100)] 
xfsprog: xfsio: update xfs_io manpage for FALLOC_FL_INSERT_RANGE

Update xfs_io manpage for FALLOC_FL_INSERT_RANGE.

Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_quota: manpage - project command requires arguments
Eric Sandeen [Thu, 5 Feb 2015 23:35:50 +0000 (10:35 +1100)] 
xfs_quota: manpage - project command requires arguments

The xfs_quota man page states that the "project" command without
arguments will list all project names and identifiers, but it has
never done this; the project_f command has always been defined as
requiring at least one argument.

Fix the man page to reflect reality.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfsprogs: do not do any dynamic linking of libtool libraries
Romain Naour [Thu, 5 Feb 2015 23:35:13 +0000 (10:35 +1100)] 
xfsprogs: do not do any dynamic linking of libtool libraries

if --disable-static and --enable-shared are given on the command
line, the link with xfsprogs's internal libraries fail because
they have been dynamically compiled.

Hence the following error:
ld: attempted static link of dynamic object `../libxcmd/.libs/libxcmd.so'

xfsprogs rely on the original behaviour of -static which was modified in
Buildroot by [1].  But since commit [2] the build of xfsprogs tools is broken
because they try to link statically with the static libuuid library
(util-linux), which is not build for shared only build.

The use of -static-libtool-libs allows to fallback to the dynamic linking for
libuuid only:

LD_TRACE_LOADED_OBJECTS=1 xfs_copy
linux-gate.so.1 =>  (0xf7793000)
libuuid.so.1 => /lib/libuuid.so.1 (0x465e1000)
libpthread.so.0 => /lib/libpthread.so.0 (0x46db1000)
librt.so.1 => /lib/librt.so.1 (0x46f21000)
libc.so.6 => /lib/libc.so.6 (0x46bf1000)
/lib/ld-linux.so.2 (0x46bce000)

[1] http://git.buildroot.net/buildroot/commit/?id=97703978ac870ce2b14ad144f8e082de82aa2c64
[2] http://git.buildroot.net/buildroot/commit/?id=f1d3e09895b245da9d54bbaef36e5de95269034e

Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_quota: fix typo in manpage
Eric Sandeen [Thu, 5 Feb 2015 23:35:12 +0000 (10:35 +1100)] 
xfs_quota: fix typo in manpage

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agorepair: check ino alignment value to avoid mod by zero
Brian Foster [Thu, 5 Feb 2015 23:32:32 +0000 (10:32 +1100)] 
repair: check ino alignment value to avoid mod by zero

xfs_repair checks inode records for valid alignment according to the
alignment specified in the superblock. It currently performs the
alignment check whenever fs_aligned_inodes is set, which is determined
based on whether the fs supports the field.

Support for the field does not guarantee its value is non-zero, however.
For example, a large block size fs on a large page size arch (e.g.,
ppc64):

mkfs.xfs -f -m crc=1,finobt=1 -b size=64k <dev>

... can lead to incorrect badly aligned inode record messages from
xfs_repair and other problems.

Update the inobt and finobt checks to verify that alignment is a
non-zero value before attempting to use it to divide (mod) by zero.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agorepair: fix v5 sb ino alignment calculation for large blocksizes
Brian Foster [Thu, 5 Feb 2015 23:31:44 +0000 (10:31 +1100)] 
repair: fix v5 sb ino alignment calculation for large blocksizes

xfs_repair validates the superblock inode alignment field against
several possible valid values. On v5 superblocks, the inode alignment
can be scaled up based on the inode size in relation to the minimum
inode size.

If the block size is larger than the default cluster size (consider
large page size arches such as ppc64), the initial alignment value
calculates to zero. If the inode size is large enough such that
sb_inoalignmt is not zero, sb_validate_ino_align() scales the align
value by the factor of inode size increase. If align is zero, however,
we multiply by zero, the subsequent check incorrectly fails and the
overall superblock verification fails as well. To reproduce, format an
fs as follows on ppc64 and run xfs_repair:

mkfs.xfs -f -m crc=1 -b size=64k -i size=2k <dev>

Fix the scaled alignment calculation by scaling the default cluster size
appropriately to avoid a multiplication by zero.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agolibxfs: report VERSION in libxfs_fs_repair_cmn_err()
Eric Sandeen [Thu, 5 Feb 2015 23:30:57 +0000 (10:30 +1100)] 
libxfs: report VERSION in libxfs_fs_repair_cmn_err()

Because this is usually the first question asked...

Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_io: add finsert command for insert range
Namjae Jeon [Thu, 5 Feb 2015 23:29:18 +0000 (10:29 +1100)] 
xfs_io: add finsert command for insert range

Add finsert command for fallocate FALLOC_FL_INSERT_RANGE flag.

Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agorepair: remove unused strided secondary sb scan logic
Brian Foster [Thu, 5 Feb 2015 23:28:52 +0000 (10:28 +1100)] 
repair: remove unused strided secondary sb scan logic

verify_set_primary_sb() scans and verifies secondary superblocks based
on the primary sb. It currently defines a maximum number of 8
superblocks to scan per iteration. It also implements a strided
algorithm that appears intended to ultimately scan every secondary,
albeit in a strided order.

Given that the algorithm is written to hit every sb and the stride value
is initialized as follows:

num_sbs = MIN(NUM_SBS, rsb->sb_agcount);
skip = howmany(num_sbs, rsb->sb_agcount);

... which is guaranteed to be 1 since the howmany() parameters are
backwards, the strided algorithm doesn't appear to accomplish anything
that can't be done with a simple for loop. In other words, despite the
max value and strided algorithm, repair always scans all of the
secondary superblocks in incremental order.

Therefore, remove the strided algorithm bits and replace with a simple
for loop. As a result of this cleanup, also remove the 'checked' buffer
used to track repeated ag visits and the now unused NUM_SBS definition.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agorepair: fix unnecessary secondary scan if only last sb is corrupt
Brian Foster [Thu, 5 Feb 2015 23:28:00 +0000 (10:28 +1100)] 
repair: fix unnecessary secondary scan if only last sb is corrupt

verify_set_primary_sb() scans the secondary superbocks based on the
geometry specified in the primary and determines the most likely correct
geometry by tracking how many superblocks are consistent across the set.
The most frequent geometry is copied into the primary superblock. The
return value is checked by the caller (phase1()) to determine whether a
brute force secondary scan is necessary.

This generally occurs when not enough secondary sb's are consistent to
declare the geometry correct. If enough secondaries are consistent,
verify_set_primary_sb() returns the status of the last secondary sb that
was scanned. Corruptions to secondary supers other than the last are
thus resolved fine. If the last secondary is corrupt, however, an error
is returned to phase1(). This causes a brute force scan even if enough
supers were found to repair the last secondary.

Move the initialization of retval to after the sb scan to return an
error only if not enough secondary supers were found to declare a
correct geometry.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_repair: fix max block offset test
Eric Sandeen [Thu, 5 Feb 2015 23:25:13 +0000 (10:25 +1100)] 
xfs_repair: fix max block offset test

Eryu pointed out that in fstest xfs/071, we find corruption
reported at the end.  This test attempts to do IO at the
maximum possible offsets, and repair yields:

inode 1027 - extent offset too large - start 70, count 1, offset 2251799813685247
correcting nextents for inode 1027
bad data fork in inode 1027
would have cleared inode 1027

Repair is complaining that an extent *starts* at the maximum
block, but AFAICT, starting there is just fine, as long as
we also end there.  i.e. a one-block extent at the limit
is just fine.

So change the xfs_repair test to allow this situation.

Also, the warning text is a bit unclear, mixing in the physical
block w/ the logical block... rearrange that a little to make
it obvious.

Reported-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_repair: do not check symlink component lengths
Eric Sandeen [Thu, 5 Feb 2015 23:24:36 +0000 (10:24 +1100)] 
xfs_repair: do not check symlink component lengths

As reported by Andy Grimm,

# ln -s $( python -c 'print "a" * 260' ) /mnt/foo

will succeed on xfs, but then xfs_repair will complain:

component of symlink in inode 131 too long
problem with symbolic link in inode 131
would have cleared inode 131

The kernel checks the total length of the symlink on both read
and write, but does not look at component paths.

Looking around the kernel, no other filesystem checks component
lengths, nor does the vfs.  And as Andy points out, the target
could even be on a different filesystem, with different limitations.

And having a "too-long" component doesn't even seem like something
likely to stem from disk corruption anyway, so I'm not sure why repair
should care.

Therefore I propose removing the component length checks from xfs_repair.

Andy Grimm <agrimm@redhat.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfsprogs: v3.2.2 release v3.2.2
Dave Chinner [Wed, 3 Dec 2014 20:56:44 +0000 (07:56 +1100)] 
xfsprogs: v3.2.2 release

Update all the version and changelog files for release.

Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agorepair: fix crash on zero record finobt reconstruction
Brian Foster [Mon, 1 Dec 2014 23:31:11 +0000 (10:31 +1100)] 
repair: fix crash on zero record finobt reconstruction

The inode btrees are reconstructed in phase 5. init_ino_cursor() helps
determine the block requirements of the tree based on the number of
records. If the finobt is empty, we can crash in the btree blocks
calculation code due to a divide-by-zero error in the following line:

lptr->modulo = num_recs % lptr->num_blocks;

This occurs if num_recs and in-turn lptr->num_blocks evaluate to zero.

We already have an execution path for the zero record btree scenario.
However, it is only invoked when no records are found in the in-core
tree. The finobt zero-record scenario can occur with a populated in-core
tree provided that none of the existing records contain free inodes.

Move the zero-record handling code after the loop and use the record
count to trigger it. This is safe because the loop iterator checks for
ino_rec != NULL. This allows reuse of the same code regardless of
whether the in-core tree is empty or non-empty but contains no records
that meet the requirements for the particular on-disk tree under
reconstruction (e.g., finobt).

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_copy: simplify first_agbno calculation
Eric Sandeen [Wed, 12 Nov 2014 23:02:22 +0000 (10:02 +1100)] 
xfs_copy: simplify first_agbno calculation

After ffe9a9a xfsprogs: xfs_copy: fix data corruption of target,
xfs_copy started hitting an ASSERT for a 4k sector / 4k blocksize
filesystem:

# dd if=/dev/zero of=test.img bs=1M count=1024
# mkfs.xfs -s size=4096 test.img
# xfs_copy test.img xfs.img
xfs_copy: xfs_copy.c:720: main: Assertion `((((((xfs_daddr_t)(3 << (mp)->m_sectbb_log)) + 1) * (1<<9)) + first_residue) % source_blocksize) == 0' failed.
Aborted

I started digging through all the calculations below, and realized
that in the end, all it wants is the first filesystem block after
the AG header.  XFS_AGFL_BLOCK(mp) + 1 suffices for this purpose;
rip out the rest which seems overly complex and apparently bug-prone.

I tested this by creating a 4g filesystem with combinations of
sector & block size between 512 and 4k, copying in /lib/modules,
running an xfs_copy of that, and running repair against the copy;
it all looks good.  It took a long time, but I will create a
simpler/shorter xfstest based on this.

Reported-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agopackaging: update deb changelog for upcoming release
Nathan Scott [Wed, 12 Nov 2014 23:02:05 +0000 (10:02 +1100)] 
packaging: update deb changelog for upcoming release

Add list of resolved issues from merged patches into the
debian/changelog for processing with the next release.

Signed-off-by: Nathan Scott <nathans@debian.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
9 years agopackaging: clarify xfs header licensing within deb builds
Nathan Scott [Wed, 12 Nov 2014 23:01:56 +0000 (10:01 +1100)] 
packaging: clarify xfs header licensing within deb builds

Tackles bug #751511 - ensuring the licensing information in
the debian/copyright file matches reality.  Use explanation
that Christoph Hellwig came up with, pretty much verbatim.

Signed-off-by: Nathan Scott <nathans@debian.org>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agopackaging: rework dh_autoreconf invocation for deb builds
Nathan Scott [Wed, 12 Nov 2014 23:01:35 +0000 (10:01 +1100)] 
packaging: rework dh_autoreconf invocation for deb builds

Reviewed, tested and merged the final iteration of proposed
solutions to #757455 - resolving configure-script-generation
for clean ppc64le builds, originally.  Many thanks to Andreas
Barth and Matthias Klose for coming up with this solution.

Signed-off-by: Nathan Scott <nathans@debian.org>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agorepair: AGFL rebuild fails if btree split required
Dave Chinner [Thu, 6 Nov 2014 23:01:00 +0000 (10:01 +1100)] 
repair: AGFL rebuild fails if btree split required

In phase 5 we rebuild the freelist btrees, the AGF and the AGFL from
all the free space information we have gathered and resolved during
pahses 3 and 4. If the freespace information is laid out just right,
we end up having to allocate free space for the AGFL blocks.

If the size of the free space we allocate from is larger than the
space we need, then we have to insert the remainder back into the
freespace btree. For the by-size tree, this means we are likely to
be removing a record from one leaf, and then inserting the remainder
- a smaller size - into another leaf.

The issue is that the leaf blocks to the left of the original leaf
block we removed the extent record from are full and hence require a
split to insert the new record. That, of course, requires a free
block in the AGFL to allocate from, and now we have a chicken and
egg situation: there are no free blocks in the AGFL because we are
setting it up.

As a result, setting up the free list silently fails, leaving the
freespace btrees in an inconsistent state and the AGFL in question
empty. When the filesystem is next mounted, the first allocation
from that AGF results in attempting to fix the AGFL, and it then
does exactly the same thing as the repair code, fails to allocate a
block during the split and fails. This results in an immediate
shutdown because the transaction doing the allocation is dirty by
this stage.

The fix for the problem is to make repair handle rebulding the btree
differently. If we leave ispace for a couple of records in each
btree leaf and node, there is never a need for a split to occur when
initially setting up the AGFL. This results in repair doing the
right thing, and hence the runtime problems after mount don't occur.
Further, add error checking the the AGFL setup code and abort repair
if we have a failure to correctly set up the AGFL so we catch this
problem at repair time, not mount time...

Reported-by: Barkley Vowk <bvowk@box.com>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agorepair: fix XR_BLD_FREE_TRACE compilation errors
Dave Chinner [Wed, 29 Oct 2014 05:35:22 +0000 (16:35 +1100)] 
repair: fix XR_BLD_FREE_TRACE compilation errors

Obviously hasn't been used for quite some time, so fix the
build problems and make it useful again.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agomkfs: don't warn about log sunit size if it was auto-discovered
Eric Sandeen [Wed, 29 Oct 2014 05:35:02 +0000 (16:35 +1100)] 
mkfs: don't warn about log sunit size if it was auto-discovered

Today, users doing a bare mkfs on storage with a large default
stripe size may be surprised to get this warning:

 log stripe unit (%d bytes) is too large (maximum is 256KiB
 log stripe unit adjusted to 32KiB

through no fault of their own.  The fallback is appropriate
and harmless, and there's no need to warn about this in the
defaults case.

However, we keep the warning if a large log stripe unit was
specified by the user on the commandline.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agomkfs: ignore stripe geom if sunit or swidth == physical sector size
Eric Sandeen [Wed, 29 Oct 2014 05:34:38 +0000 (16:34 +1100)] 
mkfs: ignore stripe geom if sunit or swidth == physical sector size

Today, this geometry:

# modprobe scsi_debug  opt_blks=2048 dev_size_mb=2048
# blockdev --getpbsz --getss --getiomin --getioopt  /dev/sdd
512
512
512
1048576

will result in a warning at mkfs time, like this:

# mkfs.xfs -f -d su=64k,sw=12 -l su=64k /dev/sdd
mkfs.xfs: Specified data stripe width 1536 is not the same as the volume stripe width 2048

because our geometry discovery thinks it looks like a
valid striping setup which the commandline is overriding.
However, a stripe unit of 512 really isn't indicative of
a proper stripe geometry.

Prior to this patch, we reset only sunit *or* swidth,
if either was equal to physical block size, but not
necessarily both.

Change the heuristic so that if either the discovered
sunit or the discovered swidth is physical block size,
we reset *both* to zero and ignore the geom completely.

While we're at it, don't pass &dummy in for multiple
arguments to blkid_get_topology(); that'll mean that
inside the function, the last assignment wins, and could
lead to unexpected results.

Reported-by: Stan Hoeppner <stan@hardwarefreak.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfs_io: add sync and syncfs commands
Eric Sandeen [Wed, 29 Oct 2014 05:33:49 +0000 (16:33 +1100)] 
xfs_io: add sync and syncfs commands

There's no easy way to invoke syncfs from the commandline,
as far as I know, so add it to xfs_io to be handy.

Add sync while we're at it, just for completeness.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfsprogs: two more completely harmless sparse nits
Eric Sandeen [Wed, 29 Oct 2014 05:33:34 +0000 (16:33 +1100)] 
xfsprogs: two more completely harmless sparse nits

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agolibxfs: fix harmless sparse endian nit
Eric Sandeen [Wed, 29 Oct 2014 05:33:15 +0000 (16:33 +1100)] 
libxfs: fix harmless sparse endian nit

h_crc is __le32 but cpu_to_be32() is... __be32.  So sparse
complains, even though it's harmless.

Although sparse is smart about bare 0s, and we could
drop the swap, other places explicitly swap to keep
things clear (I guess?) so "swap" the 0 with the proper
routine.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agolibxfs: fix endian mishap in xfs_dialloc_ag()
Eric Sandeen [Wed, 29 Oct 2014 05:32:54 +0000 (16:32 +1100)] 
libxfs: fix endian mishap in xfs_dialloc_ag()

Fixes a regression introduced by:

88fc730 xfs: use and update the finobt on inode allocation

which passed the non-swapped version of agi->agi_newino to
xfs_inobt_lookup()

Caught by make C=2, ftw!

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agoxfsctl.3: fix XFS_IOC_FSSETXATTR fields
Mark Tinguely [Wed, 29 Oct 2014 05:31:30 +0000 (16:31 +1100)] 
xfsctl.3: fix XFS_IOC_FSSETXATTR fields

The xfsctl manual page fails to mention that fsx_projid is a
setable field.

Signed-off-by: Mark Tinguely <tinguely@sgi.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
9 years agolibxfs: use structure initializers for cache_operations
Eric Sandeen [Wed, 29 Oct 2014 05:29:53 +0000 (16:29 +1100)] 
libxfs: use structure initializers for cache_operations

This makes it a lot easier for cscope etc.

Surely all modern compilers can cope?

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agoxfsprogs: add supported file attributes to xfs.5 manpage
Eric Sandeen [Mon, 15 Sep 2014 23:23:45 +0000 (09:23 +1000)] 
xfsprogs: add supported file attributes to xfs.5 manpage

The chattr(1) manpage suffers from the same problems mount(1) had:
many options listed, not kept up to date for various filesystems.

I've submitted a manpage update for chattr(1) which says to refer to
filesystem-specific manpages for supported attributes; this patch
updates xfs(5) to list the attributes supported by xfs.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agoxfs_io: add mremap command
Eric Sandeen [Mon, 15 Sep 2014 23:23:41 +0000 (09:23 +1000)] 
xfs_io: add mremap command

This adds a simple mremap command to xfs_io.

It does not take a start address; it uses the existing start
address, so the sized passed will be the new total size of the
mapping.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agoxfs_repair: preserve error state in process_shortform_attr
Eric Sandeen [Mon, 15 Sep 2014 23:23:40 +0000 (09:23 +1000)] 
xfs_repair: preserve error state in process_shortform_attr

process_shortform_attr uses the "junkit" error to track whether an
error was found, but by assigning it directly to the result of
valuecheck, previous errors are ignored, leading to unrepairable
errors of the form i.e.

"entry has INCOMPLETE flag on in shortform attribute"
or
"entry contains illegal character in shortform attribute name"

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agoxfs_repair: clear bad flags in process_dinode_int
Eric Sandeen [Mon, 15 Sep 2014 23:23:39 +0000 (09:23 +1000)] 
xfs_repair: clear bad flags in process_dinode_int

process_dinode_int() reports bad flags if dino->di_flags &
~XFS_DIFLAG_ANY - i.e. if any flags are set outside the known set.
But then instead of clearing them, it does flags &= ~XFS_DIFLAG_ANY
which keeps *only* the bad flags.  This leads to persistent,
unrepairable errors of the form:

"Bad flags set in inode XXX"

Fix this.

While we are at it, fix a couple lines which look like they used to
be continuation lines, but are no longer.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agoxfs_db: free flist on error in write_struct()
Eric Sandeen [Mon, 15 Sep 2014 23:19:37 +0000 (09:19 +1000)] 
xfs_db: free flist on error in write_struct()

One error path in write_struct() wasn't freeing the flist_t *fl
which was allocated, so it leaks.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agoxfs_io: fix leaks in parent_list()
Eric Sandeen [Mon, 15 Sep 2014 23:19:24 +0000 (09:19 +1000)] 
xfs_io: fix leaks in parent_list()

parent_list() has instances where a handle is leaked, both by going
out of scope, and on error paths.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agolibhandle: Fix handle leak in path_to_fshandle error paths
Eric Sandeen [Mon, 15 Sep 2014 23:19:08 +0000 (09:19 +1000)] 
libhandle: Fix handle leak in path_to_fshandle error paths

path_to_fshandle calls obj_to_handle, which potentially allocates a
handle, but the handle isn't freed on a subsequent error path.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agoxfs_fsr: free handlep in fsrfs
Eric Sandeen [Mon, 15 Sep 2014 23:18:56 +0000 (09:18 +1000)] 
xfs_fsr: free handlep in fsrfs

We leaked the fshandlep in both error returns and normal function
exit.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agoxfs_fsr: fix leaks & catch error in fsrfile()
Eric Sandeen [Mon, 15 Sep 2014 23:18:41 +0000 (09:18 +1000)] 
xfs_fsr: fix leaks & catch error in fsrfile()

The allocated fshandlep leaks on most error paths; restructure with
an out: target that does all necessary freeing, and initialize
filehandles to -1 so that we know whether they need to be closed on
the error path.

While we're at it, if gettmpname() fails, we still return 0 for an
error, because error is initialized to 0 and only set otherwise by
fsrfile_common.  So if gettmpname() fails, we return success from
the function even though we did no work.  Fix that as well by
initializing error to -1.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agoxfs_io: free fshandlep in parent_check()
Eric Sandeen [Mon, 15 Sep 2014 23:18:21 +0000 (09:18 +1000)] 
xfs_io: free fshandlep in parent_check()

The allocated fshandle wasn't freed in either normal
exit or error paths.

Do this, and consolidate cleanup into an out: target.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agomkfs: fix typo in output
Mark Tinguely [Mon, 15 Sep 2014 23:17:46 +0000 (09:17 +1000)] 
mkfs: fix typo in output

Fix typo in xfs.mkfs output.

Signed-off-by: Mark Tinguely <tinguely@sgi.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agorepair: Set ftype for entries in lost+found
Jan Kara [Mon, 15 Sep 2014 23:16:44 +0000 (09:16 +1000)] 
repair: Set ftype for entries in lost+found

So far all entries in lost+found had file type XFS_DIR3_FT_UNKNOWN which
is somewhat annoying as the next xfs_repair pass will find these and
report as an error. Set proper file type when creating these entries.

Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agolibhandle: fix installation for symlinked /usr
Jan Tulak [Mon, 18 Aug 2014 01:11:06 +0000 (11:11 +1000)] 
libhandle: fix installation for symlinked /usr

Canonicalize the pathnames for PKG_LIB_DIR and PKG_ROOT_LIB_DIR
before checking if they are the same.  This is required for Fedora
which doesn't have a separate /usr/lib directory anymore.

[Christoph Hellwig: reformat and change to canonical names]

Reported-by: Jan Tulak <jan@tulak.me>
Signed-off-by: Jan Tulak <jan@tulak.me>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agologprint: Fix printing of AGF and AGI buffers
Jan Kara [Fri, 18 Jul 2014 00:47:11 +0000 (10:47 +1000)] 
logprint: Fix printing of AGF and AGI buffers

Currently xfs_logprint doesn't show detailed data about AGF and AGI
buffers and instead always shows "Out of space". This is because
xfs_agf_t has additional fields and padding which we never read from
disk and thus buffer length is always smaller than the size of
xfs_agf_t or xfs_agi_t respectively.

Fix the problem by only making sure we have enough data in the buffer
to contain all the information we want to print.

Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agoquota: fix NULL pointer dereference in report_f
Jie Liu [Wed, 16 Jul 2014 03:54:47 +0000 (13:54 +1000)] 
quota: fix NULL pointer dereference in report_f

Run xfs_quota report against an invalid XFS path without desired quota
limitation is enabled will hit SEGSEGV as fs_path is uninitialized, e.g.

# xfs_quota -xc 'report -up' /invalid_path
xfs_quota: cannot setup path for mount /invalid_path: No such file or directory
Segmentation fault (core dumped)

(gdb) r -xc 'report -up' /invalid_path
xfs_quota: cannot setup path for mount /invalid_path: No such file or directory

Program received signal SIGSEGV, Segmentation fault.
0x0000000000408b4d in report_f (argc=2, argv=0x105ea70) at report.c:627
627 else if (fs_path->fs_flags & FS_MOUNT_POINT)

This patch fixes report_f() to only do report if the fs_path is initialized.

Signed-off-by: Jie Liu <jeff.liu@oracle.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agolibxcmd: make all comparisons using realpath'd paths
Eric Sandeen [Wed, 16 Jul 2014 03:53:47 +0000 (13:53 +1000)] 
libxcmd: make all comparisons using realpath'd paths

Both mountpoints and devices can be symlinks, so given a path
to look for, and mountpoints/devices from the system, use
realpath() on *everything* before making the comparison to see
if our path is a match.

So, with symlinks for mount points as well as for devices:

# ls -l /dev/mapper/testvg-lvol0
lrwxrwxrwx. 1 root root 7 Jul 11 19:24 /dev/mapper/testvg-lvol0 -> ../dm-3
# ls -l /mnt/scratch2
lrwxrwxrwx. 1 root root 12 Jul 11 19:57 /mnt/scratch2 -> /mnt/scratch

this should all work, and does now:

# xfs_quota -xc "report -h" /mnt/scratch2
User quota on /mnt/scratch (/dev/mapper/testvg-lvol0)
                        Blocks
User ID      Used   Soft   Hard Warn/Grace
---------- ---------------------------------
root            0      0      0  00 [------]

# xfs_quota -xc "report -h" /mnt/scratch
User quota on /mnt/scratch (/dev/mapper/testvg-lvol0)
                        Blocks
User ID      Used   Soft   Hard Warn/Grace
---------- ---------------------------------
root            0      0      0  00 [------]

# xfs_quota -xc "report -h" /dev/dm-3
User quota on /mnt/scratch (/dev/mapper/testvg-lvol0)
                        Blocks
User ID      Used   Soft   Hard Warn/Grace
---------- ---------------------------------
root            0      0      0  00 [------]

# xfs_quota -xc "report -h" /dev/mapper/testvg-lvol0
User quota on /mnt/scratch (/dev/mapper/testvg-lvol0)
                        Blocks
User ID      Used   Soft   Hard Warn/Grace
---------- ---------------------------------
root            0      0      0  00 [------]

The commit:

050a7f1 xfsprogs: handle symlinks etc in fs_table_initialise_mounts()

tried to fix this earlier, but only worked one way;
it compared the argument path in both given and realpath
form to the paths in getmntent, but did not compare to
the realpaths of the getmntent devices.

If we reduce everything, everywhere, to a realpath(), we've
got our best shot at finding the match.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agorepair: copy, don't clear, stripe geometry in backup SB
Eric Sandeen [Wed, 16 Jul 2014 03:52:47 +0000 (13:52 +1000)] 
repair: copy, don't clear, stripe geometry in backup SB

Today, if we have a filesystem with stripe geometry and
a damaged primary superblock, we will zero out stripe geometry
if we have copied the backup.

I'm guessing this might be because changing geometry with mount
options only updates the primary, so backups aren't guaranteed
to be current or correct.

Unfortunately, that leaves us with sb 0 w/ no geom, and backups
*with* geom, so the next repair finds the mismatch, and complains.
(In other words, the 2nd repair does not come up clean.)_
And ... the second repair copies the backup stripe geometry back
into the primary!

Rather than clearing stripe geometry in this case, just leave it
at what was found in the backup super, and inform the user that this
was done.  This leaves a consistent filesystem, and gives the user
a heads-up to double-check the result.

This can all be demonstrated and tested by running xfs/030 with
geometry set in MKFS_OPTIONS.  (To really make the test pass,
we need to filter the warning out of repair output.)

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agoxfsprogs: update debian packaging for next release
Nathan Scott [Wed, 16 Jul 2014 03:50:47 +0000 (13:50 +1000)] 
xfsprogs: update debian packaging for next release

Make a note of each of the Debian bugs resolved in this release,
so that they'll be automatically closed during next upload.

Signed-off-by: Nathan Scott <nathans@debian.org>
10 years agoxfsprogs: add a watch file into the debian packaging
Nathan Scott [Wed, 16 Jul 2014 03:49:16 +0000 (13:49 +1000)] 
xfsprogs: add a watch file into the debian packaging

Apparently it can improve some Debian tools that check it (e.g. UDD).
Resolves Debian bug #748483.

Signed-off-by: Nathan Scott <nathans@debian.org>
10 years agoxfsprogs: v3.2.1 release v3.2.1
Dave Chinner [Tue, 15 Jul 2014 04:22:37 +0000 (14:22 +1000)] 
xfsprogs: v3.2.1 release

Update all the versiona nd changelog files for release.

Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agoxfsprogs: update polish translation
Jakub Bogusz [Tue, 15 Jul 2014 04:20:10 +0000 (14:20 +1000)] 
xfsprogs: update polish translation

Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agorepair: handle uncorrected corruptions in phase 2
Dave Chinner [Fri, 11 Jul 2014 02:00:51 +0000 (12:00 +1000)] 
repair: handle uncorrected corruptions in phase 2

Some of the AG header corruptions detected by the IO verifiers
cannot be corrected in phase 2 when we do the initial scan of the
AGs. Correcting some errors cannot be done until a full rebuild of
the trees is done in phase 5.

Hence we can end up with a "clean" AGF/AGI buffer but have a
EFSCORRUPTED error on the buffer. This results in an assert failing:

ASSERT(agf_dirty || agfbuf->b_error != EFSCORRUPTED);

and repair not beign able to fix the problems it has tripped over.
Hence the assert that we corrected all corruptions in the buffers
is not valid and should be removed.

Reported-by: Hans Kraus <hans.w.kraus@gmx.at>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agolibxfs: clear the buffer error while the buffer is locked
Dave Chinner [Fri, 11 Jul 2014 02:00:28 +0000 (12:00 +1000)] 
libxfs: clear the buffer error while the buffer is locked

When releasing a buffer, the error shoul dbe cleared while the lock
is still held on the buffer to avoid racing with a new user of the
buffer.

This was pointed out in review of commit 6af7c1e ("libxfs: reused
invalidated buffers leak state and data") but the version committed
didn't have the fix. Thanks to Christoph Hellwig for checking and
pointing out the oversight.

Reported-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agorepair: get rid of BADFSINO
Dave Chinner [Tue, 8 Jul 2014 00:36:39 +0000 (10:36 +1000)] 
repair: get rid of BADFSINO

When we find a bad dirent, we "clear" the inode the inode number by
writing BADFSINO to the inode number in the entry:

#define BADFSINO        ((xfs_ino_t)0xfeffffffffffffffULL)

We then capture this bad inode number later in the same function
either in the same pass or in a later phase and junk the entry.
When we junk the entry, we write a "/" over the first character of
the dirent name, which is then detected up later by the directory
rebuild and ignored.

The issue with this is that the directory buffer can be written to
disk between the dirent being marked with BADFSINO and the directory
rebuild processing in phase 6, resulting in the directory block
verifier firing this error:

Invalid inode number 0xfeffffffffffffff
xfs_dir_ino_validate: XFS_ERROR_REPORT
Metadata corruption detected at block 0x11fbb698/0x1000
libxfs_writebufr: write verifer failed on bno 0x11fbb698/0x1000

And so will not write the *corrupt block* to disk. The result is
that we don't repair a corruption in the directory block correctly
and subsequent repair runs continue to find problems with the
directory.

We really don't need both BADFSINO *and* overwriting the dirent name
with "/" to mark an entry as junked. They both mean exactly the same
thing, so get rid of BADFSINO and only use the name junking to mark
dirents as bad. This prevents the directory data block verifier from
triggering on bad inode numbers, and so the later reread of the
block will find the junked entries correctly.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agorepair: fix quota inode handling in secondary superblocks
Dave Chinner [Tue, 8 Jul 2014 00:36:39 +0000 (10:36 +1000)] 
repair: fix quota inode handling in secondary superblocks

Changes to support separate project quota inodes changed the way
quota inodes got written to the superblock. The current code is
tailored for the needs to the kernel, where the inodes should only
be written if certain falgs are set saying a quota type is enabled.

Unfortunately, when recovering a corrupt secondary superblock, we
need to unconditionally write the quota inode fields after we
unconditionally zero the quota flags field. The result of this bug
is that the bad quota inode fields cannot be cleared and hence
always are reported by bad by repair in subsequent runs.

Fix this by directly clearing the quota inodes in the superblock
buffers so that we do need to set special flags to get
xfs_sb_to_disk() to do the right thing as setting flags leave bad
flag values in the superblock instead of bad inode numbers....

Also, when clearing the inode numbers, write them as NULLFSINO
rather than 0 as this is what the kernel will write them as if quota
is turned off.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agolibxfs: reused invalidated buffers leak state and data
Dave Chinner [Tue, 8 Jul 2014 00:36:39 +0000 (10:36 +1000)] 
libxfs: reused invalidated buffers leak state and data

When rebuilding a bad directory, repair first truncates away all the
blocks in the directory, good or bad. This removes blocks from the
bmap btree, and when those blocks are freed the bmap btree code
invalidates them. This marks the buffers LIBXFS_B_STALE so that we
don't try to write stale data from that buffer at a later time.

However, when rebuilding the directory, blocks may get reallocated
and we reuse the underlying buffers. This has two problems.

The first is that if the buffer was previously detected as having a
verifier error (i.e. an error that is leading to the block being
freed and the buffer being invalidated) then the error might still
be held in b_error. Hence the libxfs code needs to ensure that
b_error does not leak from one buffer usage context to another
after invalidation.

The second problem is that when new data is written into a buffer,
it no longer has stale contents. Hence when we write the buffer, we
need to clear the LIBXFS_B_STALE flag to ensure that the new data
gets written.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agorepair: handle directory block corruption in phase 6
Dave Chinner [Tue, 8 Jul 2014 00:36:34 +0000 (10:36 +1000)] 
repair: handle directory block corruption in phase 6

This should only occur in no-modify mode, but when we fail to find
the last extent in a directory btree due to corruption we need to
trash the directory if it's the first data block we find the error
on. That is because there is nothing to recover from the directory,
and if we try to scan it xfs_reapir segv's because nothing has been
read from disk.

Also catch a memory allocation failure in this code, too.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agoxfs_db: write command broken on 64 bit values
Dave Chinner [Tue, 8 Jul 2014 00:31:36 +0000 (10:31 +1000)] 
xfs_db: write command broken on 64 bit values

convert_args() has problesm with 64 bit fields because it tries to
shift them by 64 bits. The result of doing so is undefined by the C
standard, and so results in the unexpected behaviour of the result
being being the original value unchanged rather than 0. Hence you
can't write 64 bit fields because the code thinks that all values
other than 0 are out of range.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agorepair: support more than 25 ACLs
Dave Chinner [Tue, 8 Jul 2014 00:30:52 +0000 (10:30 +1000)] 
repair: support more than 25 ACLs

v5 superblock supports many more than 25 ACLs on an inode, but
xfs_repair still thinks that the maximum is 25. This slipped through
becase the reapir code does not share any of the kernel side ACL
code in libxfs, and instead has all it's own internal ACL
definitions.

Fix the repair code to support more than 25 ACLs and update
the ACL definitions to match the kernel definitions. In doing so,
this tickles a off-by-one bug on remote attribute maximum sizes
that is already fixed in the kernel code. So in addition to fixing
the repair code, this patch pulls in parts of the following kernel
commits:

bba719b5 xfs: fix off-by-one error in xfs_attr3_rmt_verify
0a8aa193 xfs: increase number of ACL entries for V5 superblocks

Reported-by: Michael L. Semon <mlsemon35@gmail.com>
Tested-by: Michael L. Semon <mlsemon35@gmail.com>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agorepair: Repair directory block CRC mismatches
Jan Kara [Tue, 8 Jul 2014 00:30:28 +0000 (10:30 +1000)] 
repair: Repair directory block CRC mismatches

It can happen that just CRC doesn't match for directory blocks. In that
case xfs_repair will just report the error but won't fix anything (as
further checking of the block doesn't reveal any problems). Make sure we
recompute and write out new CRC when we failed verification during
reading.

Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agomkfs: add "-m" options to the man page
Dave Chinner [Thu, 19 Jun 2014 21:48:44 +0000 (07:48 +1000)] 
mkfs: add "-m" options to the man page

Because they are missing.

Reported-by: Matthias Schniedermeyer <ms@citd.de>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agolibxfs: fix crc field handling in xfs_sb_to/from_disk
Eric Sandeen [Thu, 19 Jun 2014 02:15:33 +0000 (12:15 +1000)] 
libxfs: fix crc field handling in xfs_sb_to/from_disk

If we xfs_mdrestore an image from a non-crc filesystem, lo
and behold the restored image has gained a CRC:

# db/xfs_metadump.sh -o /dev/sdc1 - | xfs_mdrestore - test.img
# xfs_db -c "sb 0" -c "p crc" /dev/sdc1
crc = 0 (correct)
# xfs_db -c "sb 0" -c "p crc" test.img
crc = 0xb6f8d6a0 (correct)

This is because xfs_sb_from_disk doesn't fill in sb_crc,
but xfs_sb_to_disk(XFS_SB_ALL_BITS) does write the in-memory
CRC to disk - so we get uninitialized memory on disk.

Fix this by always initializing sb_crc to 0 when we read
the superblock, and masking out the CRC bit from ALL_BITS
when we write it.

This same fix has already been sent for kernelspace.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agolibxfs: don't send null bp to xfs_trans_brelse()
Eric Sandeen [Thu, 19 Jun 2014 02:15:06 +0000 (12:15 +1000)] 
libxfs: don't send null bp to xfs_trans_brelse()

In this case, if bp is null, error is set, and we send
bp to xfs_trans_brelse, which will try to dereference it.

Test whether we actualy have a buffer before we try to
free it.

Same fix as was sent for kernelspace.

Coverity spotted this.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agoxfsprogs: indicate default mount options in xfs.5 manpage
Eric Sandeen [Thu, 19 Jun 2014 02:14:41 +0000 (12:14 +1000)] 
xfsprogs: indicate default mount options in xfs.5 manpage

Not every pair of mount options indicated which was the
default, so add those.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
10 years agoxfsprogs: add mount options to xfs.5 manpage
Eric Sandeen [Thu, 19 Jun 2014 02:14:01 +0000 (12:14 +1000)] 
xfsprogs: add mount options to xfs.5 manpage

This is a straight cut and paste from the util-linux
mount manpage to xfs.5.

It's pretty much impossible for util-linux to keep up
with every filesystem out there, and Karel has more than
once expressed a wish that mount options move into fs-specific
manpages.

So, here we go.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>