On Tue, Jan 27, 2015 at 12:43:52AM +0100, Stef Bon wrote:
> 2015-01-26 22:14 GMT+01:00 Chris Murphy :
> >> 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 something el
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 the compatibility, and for caller
missing the check, use PTR_ERR(eb) if possible.
Original Message
Subject: Re: [PATCH 1/2] btrfs-progs: read_tree_block() and
read_node_slot() cleanup.
From: Noah Massey
To: Qu Wenruo
Date: 2015年01月28日 00:48
On Mon, Jan 26, 2015 at 10:12 PM, Qu Wenruo wrote:
Allow read_tree_block() and read_node_slot() to return error p
Original Message
Subject: [PATCH 1/2] btrfs-progs: Make option parsing more robust to
code modifications
From: Hugo Mills
To: ,
Date: 2015年01月27日 23:05
The current approach to option parsing, where long-only options are
selected on the basis of their position in the long_op
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
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: [] do_raw_spin_lock+0x94/0x122
[68127.807663] PGD 3003067 PUD 43e1f5067 PMD 43e030067 PTE 8003f8947060
[
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
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 option
On Mon, Jan 26, 2015 at 10:12 PM, Qu Wenruo 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 the compatibility, an
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: [] do_raw_spin_lock+0x94/0x122
[68127.807663] PGD 3003067 PUD 43e1f5067 PMD 43e030067 PTE 8003f8947060
[
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 appende
On Mon, Jan 26, 2015 at 04:26:38PM +0800, Xing Gu wrote:
> Signed-off-by: Xing Gu
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 http://vger.kernel.org/majordomo-info.html
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 w
Jeff Smith posted on Tue, 27 Jan 2015 02:21:24 -0700 as excerpted:
> I am just getting started with btrfs and wanted to test raid5. I set it
> up and thought it was setup correctly but when I run " btrfs fi usage
> /mnt/btrdata" I get the message "WARNING: RAID56 detected, not
> implemented".
Alexander Fieroch posted on Tue, 27 Jan 2015 10:12:35 +0100 as excerpted:
> 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
I am just getting started with btrfs and wanted to test raid5. I set
it up and thought it was setup correctly but when I run " btrfs fi
usage /mnt/btrdata" I get the message "WARNING: RAID56 detected, not
implemented". Does this mean I have no redundancy? I know it is
experimental and I am not
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 ker
18 matches
Mail list logo
