Jan,
It would appear that:
# fsck -- --repair /dev/storage/lv_btrfs
doesn't work, but if I put the fs-specific-options at the end:
# fsck /dev/storage/lv_btrfs -- --repair
it works fine. As we were/are discussing on irc, I also have no idea
where the ext4 lines come from. *scratcheshead*
And to save you guys some testing, here is the script I used and some
sample output:
fsck.btrfs:
========
#!/bin/sh -f
# fsck exit codes for convenience
# 0 - No errors
# 1 - Filesystem errors corrected
# 2 - System should be rebooted
# 4 - Filesystem errors left uncorrected
# 8 - Operational error
# 16 - Usage or syntax error
# 32 - Fsck canceled by user request
# 128 - Shared-library error
AUTO=false
while getopts ":aApy" c
do
case $c in
a|A|p|y) AUTO=true; echo "DEBUG: $c";;
esac
done
eval DEV=\${$#}
if [ ! -e $DEV ]; then
echo "$0: $DEV does not exist"
exit 8
fi
if $AUTO; then
echo "$0: BTRFS file system."
else
echo "If you wish to check the consistency of an BTRFS filesystem or"
echo "repair a damaged filesystem, see btrfsck(8)."
fi
exit 0
========
Output:
======
# fsck /dev/storage/lv_btrfs -- --repair
fsck from util-linux 2.20.1
DEBUG: p
DEBUG: a
/sbin/fsck.btrfs: BTRFS file system.
# fsck /dev/storage/lv_btrfs
fsck from util-linux 2.20.1
If you wish to check the consistency of an BTRFS filesystem or
repair a damaged filesystem, see btrfsck(8).
Note the "p" and "a" switches when called with custom fs switches, but
not when called standalone.
On Mon, Apr 15, 2013 at 1:01 PM, Eric Sandeen <sand...@redhat.com> wrote:
> On 4/15/13 11:45 AM, Dan McGrath wrote:
>> Jan,
>>
>> I got a chance to sit down and dig a little bit deeper into
>> `fsck.xfs`. Here is what I discovered.
>>
>> The "(a|A|y|p)" options in the XFS script appear to be nothing more
>> than the expected `fsck` options that imply automated checks (as is
>> clearly implied by the use of AUTO). While I have yet to specifically
>> test the capitalized "A", my guess is that it matches the "-A" options
>> from fsck(8) for when the system is going through the fstab. The
>> syntax itself appears to assume that the dev name is the last param
>> (as indicated by the argc/$#, which gets eval'd into the DEV
>> variable).
>>
>> After doing some tests with a hacked up version of the `fsck.xfs`
>> script, it would appear that the generic `fsck` script calls each
>> script in order and passes it some parameters to test, since if I pass
>> `fsck` some random/btrfsck switches:
>>
>> # fsck --repair /dev/storage/lv_btrfs
>>
>> I get an error back from `fsck.ext4`:
>>
>> fsck from util-linux 2.20.1
>> fsck.ext4: invalid option -- 'e'
>
> 2 things; from the fsck manpage:
>
> fsck [-sAVRTMNP] [-C [fd]] [-t fstype] [filesys...] [--]
> [fs-specific-options]
>
> so I think you need:
>
> fsck -- --repair /dev/storage/lv_btrfs
>
> But the other issues seems to be that fsck & blkid are autodetecting
> the device as ext4, not btrfs; a separate issue.
>
> -Eric
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
