Nicholas D Steeves posted on Thu, 23 Aug 2018 14:15:18 -0400 as excerpted:
>> It's in my interest to ship all tools in distros, but there's also only
>> that much what the upstream community can do. If you're going to
>> reconsider the status of btrfs-convert in Debian, please let me know.
>
> Ye
Hi -
dduper is an offline dedupe tool. Instead of reading whole file blocks and
computing checksum, It works by fetching checksum from BTRFS csum tree. This
hugely improves the performance.
dduper works like:
- Read csum for given two files.
- Find matching location.
- P
dduper is an offline dedupe tool. It works by fetching checksum from BTRFS
csum tree, instead of reading whole file blocks and computing checksum.
This tool relies on output from 'btrfs inspect-internal dump-csum' command.
Signed-off-by: Lakshmipathi.G
---
dduper | 310 ++
commit 672d599041c8 ("btrfs: Use wrapper macro for rcu string to remove
duplicate code") replaces some open coded rcu string handling with macro.
It turns out that btrfs_debug_in_rcu() is used for the first time and
the macro lacks lock/unlock of rcu string for non debug case
(i.e. when message is
On Thu, Aug 23, 2018 at 08:58:49AM -0400, Zygo Blaxell wrote:
> On Mon, Aug 20, 2018 at 08:33:49AM -0700, Darrick J. Wong wrote:
> > On Mon, Aug 20, 2018 at 11:09:32AM +1000, Dave Chinner wrote:
> > > - should we just round down the EOF dedupe request to the
> > > block before EOF so dedupe s
On 2018/08/24 0:49, David Howells wrote:
> I'm seeing the attached message generated from this line:
>
> btrfs_debug_in_rcu(fs_info,
> "btrfs_map_bio: rw %d 0x%x, sector=%llu, dev=%lu (%s id %llu), size=%u",
> bio_op(bio), bio->bi_opf, (u64)bio->bi_iter.bi_sector,
>
On 2018/8/24 上午12:44, Zygo Blaxell wrote:
> On Thu, Aug 23, 2018 at 01:10:48PM +0800, Qu Wenruo wrote:
>> On 2018/8/23 上午11:11, Zygo Blaxell wrote:
>>> This is a repro script for a btrfs bug that causes corrupted data reads
>>> when reading a mix of compressed extents and holes. The bug is
>>> r
On Tue, Aug 21, 2018 at 4:10 PM Austin S. Hemmelgarn
wrote:
> Also, once you've got the space cache set up by mounting once writable
> with the appropriate flag and then waiting for it to initialize, you
> should not ever need to specify the `space_cache` option again.
True.
I am not sure why I t
Hello everybody,
first, let me thank everybody for their advice. What I did was close
the terminal with the device delete-process running in it and fired it
up again. It took about 5 minutes of intensive IO-Usage and the data
was redistributed and and the /dev/sda/ removed from the list of
drives.
And by 4.14 I actually mean 4.14.60 or 4.14.62 (based on the
changelog). I don't think the single patch in 4.14.62 applies to your
situation.
On Thu, Aug 23, 2018 at 8:04 AM, Stefan Malte Schumacher
wrote:
> Hallo,
>
> I originally had RAID with six 4TB drives, which was more than 80
> percent full. So now I bought
> a 10TB drive, added it to the Array and gave the command to remove the
> oldest drive in the array.
>
> btrfs device del
Hi Qu,
On Sun, Jul 29, 2018 at 07:44:05AM +0800, Qu Wenruo wrote:
>
>
> On 2018年07月29日 05:34, Nicholas D Steeves wrote:
> > Resending because I forgot to CC list.
> >
> > Hi jkexcel,
> >
> > On 28 July 2018 at 16:50, jkexcel wrote:
> >>
> >> I'm an end user trying to use btrfs-convert but whe
Hi everyone,
Sorry for the delay replying, I've been busy with other work. Reply
follows inline. P.S. sorry about the table in this email that is 99
columns wide.
On Thu, Aug 09, 2018 at 01:50:46PM +0200, David Sterba wrote:
> On Sat, Jul 28, 2018 at 05:34:49PM -0400, Nicholas D Steeves wrote:
On 2018-08-23 10:04, Stefan Malte Schumacher wrote:
Hallo,
I originally had RAID with six 4TB drives, which was more than 80
percent full. So now I bought
a 10TB drive, added it to the Array and gave the command to remove the
oldest drive in the array.
btrfs device delete /dev/sda /mnt/btrfs-
On Thu, Aug 23, 2018 at 01:10:48PM +0800, Qu Wenruo wrote:
> On 2018/8/23 上午11:11, Zygo Blaxell wrote:
> > This is a repro script for a btrfs bug that causes corrupted data reads
> > when reading a mix of compressed extents and holes. The bug is
> > reproducible on at least kernels v4.1..v4.18.
>
David Sterba wrote:
> The code previously had explicit rcu_lock/unlock, now it uses the
> btrfs_debug_in_rcu helper which is supposed to provide that. It's
> possible that the helper is missing it due to some #ifdef mess, but I
> don't see it.
I preprocessed the function and extracted submit_str
On Thu, Aug 23, 2018 at 04:49:11PM +0100, David Howells wrote:
> I'm seeing the attached message generated from this line:
>
> btrfs_debug_in_rcu(fs_info,
> "btrfs_map_bio: rw %d 0x%x, sector=%llu, dev=%lu (%s id %llu), size=%u",
> bio_op(bio), bio->bi_opf, (u64)bio->bi_i
I'm seeing the attached message generated from this line:
btrfs_debug_in_rcu(fs_info,
"btrfs_map_bio: rw %d 0x%x, sector=%llu, dev=%lu (%s id %llu), size=%u",
bio_op(bio), bio->bi_opf, (u64)bio->bi_iter.bi_sector,
(u_long)dev->bdev->bd_dev, rcu_str_d
Hello everybody,
I think this might be useful:
root@mars:~# btrfs dev usage /mnt/btrfs-raid/
/dev/sda, ID: 1
Device size: 3.64TiB
Device slack: 0.00B
Data,RAID1: 7.00GiB
Metadata,RAID1: 1.00GiB
Unallocated: 3.63TiB
Yours s
Hallo,
I originally had RAID with six 4TB drives, which was more than 80
percent full. So now I bought
a 10TB drive, added it to the Array and gave the command to remove the
oldest drive in the array.
btrfs device delete /dev/sda /mnt/btrfs-raid
I kept a terminal with "watch btrfs fi show" open
On 2018/8/23 下午9:24, David Sterba wrote:
> On Tue, Aug 21, 2018 at 09:42:03AM +0800, Qu Wenruo wrote:
>> [BUG]
>> When mounting certain crafted image, btrfs will trigger kernel BUG_ON()
>> when try to recover balance:
>> --
>> [ cut here ]
>
> Please don't use lines s
On Tue, Aug 21, 2018 at 09:42:03AM +0800, Qu Wenruo wrote:
> [BUG]
> When mounting certain crafted image, btrfs will trigger kernel BUG_ON()
> when try to recover balance:
> --
> [ cut here ]
Please don't use lines starting with ---, an empty line is fine, or you
can al
On Tue, Aug 21, 2018 at 09:42:03AM +0800, Qu Wenruo wrote:
> [BUG]
> When mounting certain crafted image, btrfs will trigger kernel BUG_ON()
> when try to recover balance:
> --
> [ cut here ]
> kernel BUG at fs/btrfs/extent-tree.c:8956!
> invalid opcode: [#1] PREEMP
On Mon, Aug 20, 2018 at 08:33:49AM -0700, Darrick J. Wong wrote:
> On Mon, Aug 20, 2018 at 11:09:32AM +1000, Dave Chinner wrote:
> > - is documenting rejection on request alignment grounds
> > (i.e. EINVAL) in the man page sufficient for app
> > developers to understand what is goin
On Thu, Aug 23, 2018 at 03:14:53AM +0800, Liu Bo wrote:
> As next_state() is already defined to get the next state, update us to use
> the helper.
>
> No functional changes.
>
> Signed-off-by: Liu Bo
Added to misc-next, thanks.
On 22.08.2018 22:51, Liu Bo wrote:
> Several structs in btrfs are using rb_first() in a while loop, it'd be
> more efficient to do this with rb_first_cached() which has the O(1)
> complexity.
>
> This patch set updates five structs which may have a large rb tree in
> practice
>
> Liu Bo (5):
>
On 08/22/18 21:51, Liu Bo wrote:
Several structs in btrfs are using rb_first() in a while loop, it'd be
more efficient to do this with rb_first_cached() which has the O(1)
complexity.
This patch set updates five structs which may have a large rb tree in
practice
Great idea, works for me with n
On 2018/8/23 下午3:36, Nikolay Borisov wrote:
>
>
> On 23.08.2018 10:31, Qu Wenruo wrote:
>> Introduce --breadth-first option to do breadth-first tree dump.
>> This is especially handy to inspect high level trees, e.g. comparing
>> tree reloc tree with its source tree.
>
> Will it make sense in
On 08/23/2018 03:31 PM, Qu Wenruo wrote:
By default dump-tree does depth-first search.
For 2 level trees it's completely OK, but for 3 level trees, it would be
pretty hard to locate output of middle level tree nodes.
Introduce --breadth-first option to do breadth-first tree dump.
This is esp
On 23.08.2018 10:31, Qu Wenruo wrote:
> Introduce --breadth-first option to do breadth-first tree dump.
> This is especially handy to inspect high level trees, e.g. comparing
> tree reloc tree with its source tree.
Will it make sense instead of exposing another option to just have a
heuristics
By default dump-tree does depth-first search.
For 2 level trees it's completely OK, but for 3 level trees, it would be
pretty hard to locate output of middle level tree nodes.
Introduce --breadth-first option to do breadth-first tree dump.
This is especially handy to inspect high level trees, e.g
31 matches
Mail list logo
