On 11/28/2017 12:05 PM, Qu Wenruo wrote:
On 2017年11月28日 10:38, Su Yue wrote:
Thanks for review.
On 11/27/2017 06:37 PM, Qu Wenruo wrote:
On 2017年11月27日 11:13, Su Yue wrote:
Commit d17d6663c99c ("btrfs-progs: lowmem check: Fix regression which
screws up extent allocator") removes pin_met
[BUG]
fstrim on some btrfs only trims the unallocated space, not trimming any
space in existing block groups.
[CAUSE]
Before fstrim_range passed to btrfs_trim_fs(), it get truncated to
range [0, super->total_bytes).
So later btrfs_trim_fs() will only be able to trim block groups in range
[0, super
Function btrfs_trim_fs() doesn't handle errors in a consistent way, if
error happens when trimming existing block groups, it will skip the
remaining blocks and continue to trim unallocated space for each device.
And the return value will only reflect the final error from device
trimming.
This pat
[BUG]
fstrim on some btrfs only trims the unallocated space, not trimming any
space in existing block groups.
[CAUSE]
Before fstrim_range passed to btrfs_trim_fs(), it get truncated to
range [0, super->total_bytes).
So later btrfs_trim_fs() will only be able to trim block groups in range
[0, super
On 28.11.2017 09:03, Qu Wenruo wrote:
>
>
> On 2017年11月28日 14:59, Nikolay Borisov wrote:
>>
>>
>> On 28.11.2017 02:37, Qu Wenruo wrote:
>>>
>>>
>>> On 2017年11月27日 23:29, Nikolay Borisov wrote:
On 27.11.2017 15:23, Adam Borowski wrote:
> Hi!
> On 4.15-rc1, I get the follow
On 2017年11月28日 14:59, Nikolay Borisov wrote:
>
>
> On 28.11.2017 02:37, Qu Wenruo wrote:
>>
>>
>> On 2017年11月27日 23:29, Nikolay Borisov wrote:
>>>
>>>
>>> On 27.11.2017 15:23, Adam Borowski wrote:
Hi!
On 4.15-rc1, I get the following failure:
BTRFS critical (device sda1): co
On 28.11.2017 02:37, Qu Wenruo wrote:
>
>
> On 2017年11月27日 23:29, Nikolay Borisov wrote:
>>
>>
>> On 27.11.2017 15:23, Adam Borowski wrote:
>>> Hi!
>>> On 4.15-rc1, I get the following failure:
>>>
>>> BTRFS critical (device sda1): corrupt leaf: root=1 block=3820662898688
>>> slot=43 ino=35691
On 2017年11月28日 10:38, Su Yue wrote:
> Thanks for review.
>
> On 11/27/2017 06:37 PM, Qu Wenruo wrote:
>>
>>
>> On 2017年11月27日 11:13, Su Yue wrote:
>>> Commit d17d6663c99c ("btrfs-progs: lowmem check: Fix regression which
>>> screws up extent allocator") removes pin_metadata_blocks() from
>>> low
This patch creates a helper function to get either the rcu device path
or missing.
Signed-off-by: Anand Jain
---
fs/btrfs/dev-replace.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/fs/btrfs/dev-replace.c b/fs/btrfs/dev-replace.c
index 7c655f9a7a50.
Thanks for review.
On 11/27/2017 06:37 PM, Qu Wenruo wrote:
On 2017年11月27日 11:13, Su Yue wrote:
Commit d17d6663c99c ("btrfs-progs: lowmem check: Fix regression which
screws up extent allocator") removes pin_metadata_blocks() from
lowmem repair.
So we have to find another way to exclude extent
On Tue, Nov 28, 2017 at 08:51:07AM +0800, Qu Wenruo wrote:
> On 2017年11月27日 22:22, David Sterba wrote:
> > On Mon, Nov 27, 2017 at 02:23:49PM +0100, Adam Borowski wrote:
> >> On 4.15-rc1, I get the following failure:
> >>
> >> BTRFS critical (device sda1): corrupt leaf: root=1 block=3820662898688
>
On 2017年11月27日 22:22, David Sterba wrote:
> On Mon, Nov 27, 2017 at 02:23:49PM +0100, Adam Borowski wrote:
>> Hi!
>> On 4.15-rc1, I get the following failure:
>>
>> BTRFS critical (device sda1): corrupt leaf: root=1 block=3820662898688
>> slot=43 ino=35691 file_offset=0, invalid ram_bytes for unc
On 2017年11月28日 07:21, David Sterba wrote:
> On Wed, Nov 01, 2017 at 09:30:40AM +0800, Qu Wenruo wrote:
>> +u64 btrfs_min_dev_size(u32 nodesize, int mixed, u64 meta_profile,
>> + u64 data_profile)
>> +{
>> +u64 reserved = 0;
>> +u64 meta_size;
>> +u64 data_size;
>> +
On 2017年11月27日 23:29, Nikolay Borisov wrote:
>
>
> On 27.11.2017 15:23, Adam Borowski wrote:
>> Hi!
>> On 4.15-rc1, I get the following failure:
>>
>> BTRFS critical (device sda1): corrupt leaf: root=1 block=3820662898688
>> slot=43 ino=35691 file_offset=0, invalid ram_bytes for uncompressed in
On Wed, Nov 01, 2017 at 09:30:42AM +0800, Qu Wenruo wrote:
> So prepare_test_dev() can be called several times in one test case, to
> test different device sizes.
>
> Signed-off-by: Qu Wenruo
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body o
On Wed, Nov 01, 2017 at 09:30:41AM +0800, Qu Wenruo wrote:
> For later test case which needs info from stderr.
>
> Signed-off-by: Qu Wenruo
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 majord
On Wed, Nov 01, 2017 at 09:30:40AM +0800, Qu Wenruo wrote:
> +u64 btrfs_min_dev_size(u32 nodesize, int mixed, u64 meta_profile,
> +u64 data_profile)
> +{
> + u64 reserved = 0;
> + u64 meta_size;
> + u64 data_size;
> +
> + if (mixed)
> + return 2 * (BT
On Fri, Nov 24, 2017 at 02:21:15PM +0900, Misono, Tomohiro wrote:
> Currently, only the status of block devices is checked at mkfs,
> but we should also check for regular files whether they are already
> formatted or mounted to prevent overwrite accidentally.
>
> Device status is checked by test_d
On Tue, Nov 07, 2017 at 10:24:30AM +0800, Su Yue wrote:
> In function cmd_filesystem_defrag(), lines of code for error handling
> are duplicate and hard to expand in further.
>
> Create a jump label for errors.
>
> Signed-off-by: Su Yue
> ---
> cmds-filesystem.c | 46 +--
On Fri, Nov 10, 2017 at 09:34:17AM +0800, Qu Wenruo wrote:
> Tree reloc tree is a special tree with very short life spawn.
> It acts as a special snapshot for any tree, with related nodes/leaves or
> EXTENT_DATA modified to point to new position.
>
> Considering the short life spawn and its specia
On Fri, Nov 10, 2017 at 05:47:10PM +0800, Lu Fengqi wrote:
> This error occurs when no_holes is not set, but there is a gap
> before the file extent.
>
> Signed-off-by: Lu Fengqi
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message t
On Wed, Nov 22, 2017 at 04:16:04PM -0500, Josef Bacik wrote:
> From: Josef Bacik
> @@ -4802,8 +4885,8 @@ struct extent_buffer *btrfs_clone_extent_buffer(struct
> extent_buffer *src)
> return new;
> }
>
> -struct extent_buffer *__alloc_dummy_extent_buffer(struct btrfs_fs_info
> *fs_info,
On Thu, Nov 23, 2017 at 10:51:43AM +0200, Nikolay Borisov wrote:
> Commit 9036c10208e1 ("Btrfs: update hole handling v2") added the FLAG_VACANCY
> to denote holes, however there was already a consistent way of flagging
> extents which represent hole - ->block_start = EXTENT_MAP_HOLE. And also
> the
On Fri, Nov 17, 2017 at 03:14:19PM +0800, Qu Wenruo wrote:
> This function is no longer used outside of extent-tree.c.
> Make it static.
>
> Signed-off-by: Qu Wenruo
Reviewed-by: David Sterba
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to m
On Tue, Nov 21, 2017 at 02:35:40PM -0700, Liu Bo wrote:
> Xfstests btrfs/146 revealed this corruption,
>
> [ 58.138831] Buffer I/O error on dev dm-0, logical block 2621424, async
> page read
> [ 58.151233] BTRFS error (device sdf): bdev /dev/mapper/error-test errs: wr
> 1, rd 0, flush 0, cor
On Sat, Nov 25, 2017 at 09:03:26AM +0800, Qu Wenruo wrote:
> On 2017年11月25日 04:26, Hans van Kranenburg wrote:
> > -# btrfs inspect-internal dump-tree -t fs /dev/block/device
> > ERROR: unrecognized tree id: fs
> >
> > Without this fix I can't dump-tree fs, but I can dump-tree fs_tree and
> > also
On 27.11.2017 15:23, Adam Borowski wrote:
> Hi!
> On 4.15-rc1, I get the following failure:
>
> BTRFS critical (device sda1): corrupt leaf: root=1 block=3820662898688
> slot=43 ino=35691 file_offset=0, invalid ram_bytes for uncompressed inline
> extent, have 134 expect 281474976710677
>
> Repea
On Mon, Nov 27, 2017 at 02:23:49PM +0100, Adam Borowski wrote:
> Hi!
> On 4.15-rc1, I get the following failure:
>
> BTRFS critical (device sda1): corrupt leaf: root=1 block=3820662898688
> slot=43 ino=35691 file_offset=0, invalid ram_bytes for uncompressed inline
> extent, have 134 expect 2814749
Test case btrfs-progs test-misc/012 can recreate the same fsid with
different number of struct btrfs_fs_devices::total_devices. And the
previous device which is in the kernel device list is stale now. But
as we don't clean the kernel device list (unless same device is scanned
with different fsid),
On 2017-11-27 08:17, Qu Wenruo wrote:
On 2017年11月27日 21:02, Austin S. Hemmelgarn wrote:
On 2017-11-27 05:13, Qu Wenruo wrote:
On 2017年11月27日 17:41, Lu Fengqi wrote:
Hi all,
As we all know, under certain circumstances, it is more appropriate to
create some subvolumes rather than keep every
Hi!
On 4.15-rc1, I get the following failure:
BTRFS critical (device sda1): corrupt leaf: root=1 block=3820662898688
slot=43 ino=35691 file_offset=0, invalid ram_bytes for uncompressed inline
extent, have 134 expect 281474976710677
Repeatable every boot attempt. 4.14 and earlier boot fine; btrfs
On 2017年11月27日 21:02, Austin S. Hemmelgarn wrote:
> On 2017-11-27 05:13, Qu Wenruo wrote:
>>
>>
>> On 2017年11月27日 17:41, Lu Fengqi wrote:
>>> Hi all,
>>>
>>> As we all know, under certain circumstances, it is more appropriate to
>>> create some subvolumes rather than keep everything in the same
>
On 2017-11-27 05:06, Dmitrii Tcvetkov wrote:
On Mon, 27 Nov 2017 09:06:12 +0100
Daniel Pocock wrote:
Hi all,
The FAQ has a couple of sections on encryption (general and dm-crypt)
One thing that isn't explained there: if you create multiple encrypted
volumes (e.g. using dm-crypt) and use Btrf
On 2017-11-27 05:13, Qu Wenruo wrote:
On 2017年11月27日 17:41, Lu Fengqi wrote:
Hi all,
As we all know, under certain circumstances, it is more appropriate to
create some subvolumes rather than keep everything in the same
subvolume. As the condition of demand change, the user may need to
convert
Hi Lakshmipathi,
Oops I can see the same. I am trying to narrow down.
Thanks, Anand
On 11/27/2017 02:47 PM, Lakshmipathi.G wrote:
Hi Anand,
With this patch applied, btrfs-progs/misc-test/021 error out. Is this
same for you?
Without this patch: https://asciinema.org/a/RJmE5469mHlL3S1BIOCifW
On 2017年11月27日 11:13, Su Yue wrote:
> Commit d17d6663c99c ("btrfs-progs: lowmem check: Fix regression which
> screws up extent allocator") removes pin_metadata_blocks() from
> lowmem repair.
> So we have to find another way to exclude extents which should be
> occupied by tree blocks.
First thin
On 2017年11月27日 11:13, Su Yue wrote:
> In lowmem mode with '--repair', check_chunks_and_extents_v2()
> will fix accounting in block groups and clear the error
> bit BG_ACCOUNTING_ERROR.
> However, return value of check_btrfs_root() is 0 either 1 instead of
> error bits.
>
> If extent tree is on e
On 2017年11月27日 11:13, Su Yue wrote:
> In repair_extent_data_item(), path is not be released if some
> errors occurs which causes extent buffer leak.
>
> So release path in end of the function.
>
> Signed-off-by: Su Yue
> ---
> cmds-check.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(
On 2017年11月27日 17:41, Lu Fengqi wrote:
> Hi all,
>
> As we all know, under certain circumstances, it is more appropriate to
> create some subvolumes rather than keep everything in the same
> subvolume. As the condition of demand change, the user may need to
> convert a previous directory to a su
On Mon, 27 Nov 2017 09:06:12 +0100
Daniel Pocock wrote:
> Hi all,
>
> The FAQ has a couple of sections on encryption (general and dm-crypt)
>
> One thing that isn't explained there: if you create multiple encrypted
> volumes (e.g. using dm-crypt) and use Btrfs to combine them into
> RAID1, how
Hi all,
As we all know, under certain circumstances, it is more appropriate to
create some subvolumes rather than keep everything in the same
subvolume. As the condition of demand change, the user may need to
convert a previous directory to a subvolume. For this reason，how about
adding an ioctl to
Hi all,
The FAQ has a couple of sections on encryption (general and dm-crypt)
One thing that isn't explained there: if you create multiple encrypted
volumes (e.g. using dm-crypt) and use Btrfs to combine them into RAID1,
how does error recovery work when a read operation returns corrupted data?
42 matches
Mail list logo
