On Wed, Oct 24, 2018 at 01:48:40PM +0100, Filipe Manana wrote:
> On Wed, Oct 24, 2018 at 1:40 PM Josef Bacik wrote:
> >
> > On Wed, Oct 24, 2018 at 12:53:59PM +0100, Filipe Manana wrote:
> > > On Wed, Oct 24, 2018 at 12:37 PM Josef Bacik wrote:
> > > >
> > > > On Wed, Oct 24, 2018 at 10:13:03AM +
On Fri, Oct 12, 2018 at 04:25:23PM +0800, robbieko wrote:
> From: Robbie Ko
>
> super-recover collects btrfs devices information using existed
> functions scan_one_devices().
>
> Problem is fs_devices is freed twice. One in __open_ctree_fd() when
> error happens and the other in btrfs_close_devi
On Wed, Oct 24, 2018 at 9:03 AM, Dmitry Katsubo wrote:
> On 2018-10-17 00:14, Dmitry Katsubo wrote:
>>
>> As a workaround I can monitor dmesg output but:
>>
>> 1. It would be nice if I could tell btrfs that I would like to mount
>> read-only
>> after a certain error rate per minute is reached.
>>
On Thu, Sep 13, 2018 at 03:05:04PM +0300, Nikolay Borisov wrote:
> While looking at check_file_extent I thought that the code might be a bit
> cleaner than it actually is and cleaner as well. The first patch factors out
> the code dealing with inline extents into a separate function aptly named
On Mon, Oct 22, 2018 at 6:22 PM David Sterba wrote:
>
> this is the first batch with fixes and some nice performance improvements.
Pulled (at 30,000 ft, somewhere between Ireland and Iceland),
Linus
On Fri, Oct 12, 2018 at 03:41:53PM +0800, Su Yanjun wrote:
> When using gcc8 to compile btrfs-progs, it complains as below:
>
> ctree.c: In function 'btrfs_search_slot_for_read':
> ctree.c:1249:45: warning: passing argument 3 of 'btrfs_search_slot'
> discards 'const' qualifier from pointer
On Fri, Oct 12, 2018 at 09:36:37AM +0800, Su Yanjun wrote:
> When using gcc8 compiles utils.c, it complains as below:
>
> utils.c:852:45: warning: '%s' directive output may be truncated writing
> up to 4095 bytes into a region of size 4084 [-Wformat-truncation=]
>snprintf(path, sizeof(path), "
On Tue, Sep 18, 2018 at 09:17:54AM +0800, Su Yanjun wrote:
> Modify the file name length limit to meet the Linux naming convention.
> In addition, the file name length is always bigger than 0, no need to
> compare with 0 again.
>
> Changelog:
> v2:
> Fix the same problem in creating snapshot rout
On Tue, Sep 18, 2018 at 04:44:48PM +0800, Su Yanjun wrote:
> Total of three conditions are tested. One for short name, one with
> name length 255, the last one with more than 255.
>
> This case should pass after commit
> 'btrfs-progs: change filename limit to 255 when creating subvolume'.
>
> Sig
On Fri, Sep 14, 2018 at 03:25:03PM +0800, Qu Wenruo wrote:
> This patchset can be fetched from github:
> https://github.com/adam900710/btrfs-progs/tree/convert_error_messages
> As usual, it's based on latest stable tag (v4.17.1).
>
> There is one error report of btrfs-convert, the error message lo
On 2018-10-17 00:14, Dmitry Katsubo wrote:
As a workaround I can monitor dmesg output but:
1. It would be nice if I could tell btrfs that I would like to mount
read-only
after a certain error rate per minute is reached.
2. It would be nice if btrfs could detect that both drives are not
availa
On 24.10.18 г. 15:30 ч., David Sterba wrote:
> On Fri, Oct 12, 2018 at 05:57:29PM +0800, Qu Wenruo wrote:
>> +printf("log_root_transid (deprecated)\t%llu\n",
>> + le64_to_cpu(sb->__unused_log_root_transid));
>
> This should be entirely removed.
It
On Fri, Oct 12, 2018 at 05:57:29PM +0800, Qu Wenruo wrote:
> +printf("log_root_transid (deprecated)\t%llu\n",
> + le64_to_cpu(sb->__unused_log_root_transid));
> >>>
> >>> This should be entirely removed.
> >>
> >> It looks OK to me.
> >> Just like the old leafsize.
>
On Wed, Oct 24, 2018 at 12:11:28PM +0200, David Sterba wrote:
> On Tue, Oct 23, 2018 at 10:17:28PM +0100, Phillip Potter wrote:
> > Deduplicate the btrfs file type conversion implementation.
>
> The per-filesystem changelogs need a brief explanation why this is done,
> like "Filesystems that use t
On Wed, Oct 24, 2018 at 1:40 PM Josef Bacik wrote:
>
> On Wed, Oct 24, 2018 at 12:53:59PM +0100, Filipe Manana wrote:
> > On Wed, Oct 24, 2018 at 12:37 PM Josef Bacik wrote:
> > >
> > > On Wed, Oct 24, 2018 at 10:13:03AM +0100, fdman...@kernel.org wrote:
> > > > From: Filipe Manana
> > > >
> > >
On Wed, Oct 24, 2018 at 12:53:59PM +0100, Filipe Manana wrote:
> On Wed, Oct 24, 2018 at 12:37 PM Josef Bacik wrote:
> >
> > On Wed, Oct 24, 2018 at 10:13:03AM +0100, fdman...@kernel.org wrote:
> > > From: Filipe Manana
> > >
> > > When we are writing out a free space cache, during the transactio
When running generic/475, pinned underflow may occur. This patch will
fix this problem, but there are still other warnings need to addressed in
this case.
Patch 1-2 introduce a macro and wrappers to help detect underflow
Patch 3 the fix patch of pinned underflow
Lu Fengqi (2):
btrfs: extent-tre
Introduce a new wrapper update_bytes_pinned to replace open coded
bytes_pinned modifiers.
Signed-off-by: Lu Fengqi
---
fs/btrfs/extent-tree.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index c0147a1307e7..bb91db944
From: Qu Wenruo
Although we have space_info::bytes_may_use underflow detection in
btrfs_free_reserved_data_space_noquota(), we have more callers who are
subtracting number from space_info::bytes_may_use.
So instead of doing underflow detection for every caller, introduce a
new wrapper update_byt
When running generic/475, we may get the following warning in the dmesg.
[ 6902.102154] WARNING: CPU: 3 PID: 18013 at fs/btrfs/extent-tree.c:9776
btrfs_free_block_groups+0x2af/0x3b0 [btrfs]
[ 6902.104886] Modules linked in: btrfs(O) xor zstd_decompress zstd_compress
xxhash raid6_pq efivarfs xfs
On Wed, Oct 24, 2018 at 12:37 PM Josef Bacik wrote:
>
> On Wed, Oct 24, 2018 at 10:13:03AM +0100, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > When we are writing out a free space cache, during the transaction commit
> > phase, we can end up in a deadlock which results in a stack tr
On Wed, Oct 24, 2018 at 10:13:03AM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> When we are writing out a free space cache, during the transaction commit
> phase, we can end up in a deadlock which results in a stack trace like the
> following:
>
> schedule+0x28/0x80
> btrfs_tree
On Tue, Oct 23, 2018 at 10:17:28PM +0100, Phillip Potter wrote:
> Deduplicate the btrfs file type conversion implementation.
The per-filesystem changelogs need a brief explanation why this is done,
like "Filesystems that use the same filetypes as defined by POSIX do not
need to define their own ve
From: Filipe Manana
When we are writing out a free space cache, during the transaction commit
phase, we can end up in a deadlock which results in a stack trace like the
following:
schedule+0x28/0x80
btrfs_tree_read_lock+0x8e/0x120 [btrfs]
? finish_wait+0x80/0x80
btrfs_read_lock_root_node+0x2
On Wed, Oct 24, 2018 at 5:08 AM Josef Bacik wrote:
>
> On Mon, Oct 22, 2018 at 11:05:08PM +0100, Filipe Manana wrote:
> > On Mon, Oct 22, 2018 at 8:18 PM Josef Bacik wrote:
> > >
> > > On Mon, Oct 22, 2018 at 08:10:37PM +0100, fdman...@kernel.org wrote:
> > > > From: Filipe Manana
> > > >
> > >
25 matches
Mail list logo
