Hello,
I'm testing btrfs RAID5 on three encrypted hdds (dm-crypt) and I'm
simulating a harddisk failure by unplugging one device while writing
some files.
Now the filesystem is damaged. By now is there any chance to repair the
filesystem?
My operating system is ubuntu server (vivid) with
Yeah, copying them all back on has gone event free, now running some
balance passes to clear up the 310G of slack allocation.
I did realize that something I'd claimed earlier wasn't true: there
were 3 files larger than a gig in the apt mirror snapshots, so large
files in snapshots could have been
While running a scrub on a kernel with CONFIG_DEBUG_PAGEALLOC=y, I got
the following trace:
[68127.807663] BUG: unable to handle kernel paging request at 8803f8947a50
[68127.807663] IP: [8107da31] do_raw_spin_lock+0x94/0x122
[68127.807663] PGD 3003067 PUD 43e1f5067 PMD 43e030067 PTE
Original Message
Subject: [PATCH 1/2] btrfs-progs: Make option parsing more robust to
code modifications
From: Hugo Mills h...@carfax.org.uk
To: linux-btrfs@vger.kernel.org, dste...@suse.cz
Date: 2015年01月27日 23:05
The current approach to option parsing, where long-only
Gareth Pye posted on Wed, 28 Jan 2015 08:53:01 +1100 as excerpted:
Thank you all for your help. This file systems possibilities do excite
me, the future is bright.
And a final thank you. Glad we were able to help you do what you
wanted/needed to do. Sometimes we never know if it worked, and
Particularly during support conversations, people get confused about
which options to use with btrfs check. Adding a flag, --readonly, which
implies the default read-only behaviour and which conflicts with the
read-write operations, should help make the behaviour of the tool clear.
Signed-off-by:
The current approach to option parsing, where long-only options are
selected on the basis of their position in the long_options array is
fragile and painful to modify if options are to be inserted into the
list, rather than appended.
Instead, use the last field of struct option to return a value
On Mon, Jan 26, 2015 at 10:12 PM, Qu Wenruo quwen...@cn.fujitsu.com wrote:
Allow read_tree_block() and read_node_slot() to return error pointer.
This should help caller to get more specified error number.
For existing callers, change (!eb) judgmentt to
(!extent_buffer_uptodate(eb)) to keep
On Mon, Jan 26, 2015 at 04:26:38PM +0800, Xing Gu wrote:
Signed-off-by: Xing Gu gux.f...@cn.fujitsu.com
Applied, thanks.
--
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
On Tue, Jan 27, 2015 at 03:05:52PM +, Hugo Mills wrote:
The current approach to option parsing, where long-only options are
selected on the basis of their position in the long_options array is
fragile and painful to modify if options are to be inserted into the
list, rather than appended.
While running a scrub on a kernel with CONFIG_DEBUG_PAGEALLOC=y, I got
the following trace:
[68127.807663] BUG: unable to handle kernel paging request at 8803f8947a50
[68127.807663] IP: [8107da31] do_raw_spin_lock+0x94/0x122
[68127.807663] PGD 3003067 PUD 43e1f5067 PMD 43e030067 PTE
Hi,
this is probably the last release before 3.19 unless something urgent pops up.
I'm going to start 3.19 with the autotools update and merge the bigger
patchsets (restore, find-root, check/repair).
Changes:
* qgroup show: print human readable sizes, options to say otherwise
* check: new
On Tue, Jan 27, 2015 at 12:43:52AM +0100, Stef Bon wrote:
2015-01-26 22:14 GMT+01:00 Chris Murphy li...@colorremedies.com:
is there a way to get the difference between these two files by making
use of btrfs?
Snapper has this functionality built into it. I'm not sure if it uses
diff or
13 matches
Mail list logo
