Linux mcplex 3.18.4-gentoo #1 SMP Wed Jan 28 22:25:43 EST 2015 x86_64
Intel(R) Core(TM) i7-2600S CPU @ 2.80GHz GenuineIntel GNU/Linux
--
Sandy McArthur, Jr.
"No nation could preserve its freedom in the midst of continual warfare."
- Letters and Other Writings of James Madison (18
Does a btrfs scrub verify the integrity of the whole filesystem or
just the data in that filesystem?
I recently removed some unreliable drives from my multi-volume RAID1
btrfs filesystem and ran a scrub that completed with two corrected
errors (see below). I've struggled with this filesystem due
corrected errors: 512, uncorrectable errors: 1, unverified errors: 0
Still, the output when wrapping up is still not intuitive to me:
"scrub started at Tue Jan 13 01:18:22 2015, interrupted after 136982
seconds, not running"
On Wed, Jan 14, 2015 at 4:06 PM, Sandy McArthur Jr wrote:
> So
fs v3.18.1
--
Sandy McArthur Jr
"He who dares not offend cannot be honest."
- Thomas Paine
--
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
On Sun, Dec 7, 2014 at 12:50 AM, Sandy McArthur Jr wrote:
> Would the `btrfs check` output below indicate "only small error" and
> that a --repair is likely to succeed?
It did. Thanks Qu and Duncan.
dmesg suggests I have some scrubbing to do:
[220283.369150] BTRFS: bdev /dev/sdh
> Original Message
> Subject: If btrfs-find-root doesn't find tree roots is the filesystem lost?
> From: Sandy McArthur Jr
> To: linux-btrfs@vger.kernel.org
> Date: 2014年12月04日 09:20
>>
>> I have a many-disk btrfs filesystem that I cannot access after
I have a many-disk btrfs filesystem that I cannot access after a
crash. When I run btrfs-find-root I get lots of "Well block [#] seems
great [...]" lines but zero "Generation: [...]" lines.
Is this filesystem lost?
Context info below. I'll upgrade to a 3.17.4 kernel soon and try again
just in cas
