On 21.06.2018 11:38, Su Yue wrote:
>
>
> On 06/20/2018 11:43 PM, Nikolay Borisov wrote:
>> Currently the function uses 2 goto labels to properly handle allocation
>> failures. This could be simplified by simply re-arranging the code so
>> that allocations are the in the beginning of the
Currently the function uses 2 goto labels to properly handle allocation
failures. This could be simplified by simply re-arranging the code so
that allocations are the in the beginning of the function. This allows
to use simple return statements. No function changes.
Signed-off-by: Nikolay Borisov
On Thu, Jun 21, 2018 at 03:04:22PM +0800, Lu Fengqi wrote:
> Since btrfs-dump-tree has been removed from btrfs-progs, use btrfs
> inspect-internal dump-tree instead of btrfs-dump-tree.
>
> Signed-off-by: Lu Fengqi
Then there's no user of $BTRFS_DEBUG_TREE_PROG, I think we could remove
the
On 20.06.2018 20:51, David Sterba wrote:
> This patchset fixes the bugs recently reported by syzbot. I've tried to
> use patches from Anand [1] to fix that but in the end there were fixes
> not suitable for merging to 4.18 and my final fix took a different
> approach.
>
> In short,
Since btrfs-dump-tree has been removed from btrfs-progs, use btrfs
inspect-internal dump-tree instead of btrfs-dump-tree.
Signed-off-by: Lu Fengqi
---
tests/btrfs/085 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/btrfs/085 b/tests/btrfs/085
index
On 21.06.2018 10:04, Lu Fengqi wrote:
> Since btrfs-dump-tree has been removed from btrfs-progs, use btrfs
> inspect-internal dump-tree instead of btrfs-dump-tree.
>
> Signed-off-by: Lu Fengqi
Reviewed-by: Nikolay Borisov
> ---
> tests/btrfs/085 | 4 ++--
> 1 file changed, 2
On Wed, Jun 20, 2018 at 03:38:58PM +0800, Qu Wenruo wrote:
> Commit f8f84b2dfda5 ("btrfs: index check-integrity state hash by a dev_t")
> changed how btrfsic how we index device state hash.
>
> Now we need to access device->bdev->bd_dev, while for degraded mount
> it's completely possible to have
On Wed, Jun 20, 2018 at 05:26:42PM +0300, Nikolay Borisov wrote:
> Currently this function takes the root as an argument only to get the
> log_root from it. Simplify this by directly passing the log root from
> the caller. Also eliminate the fs_info local var, since it's used only
> once, so
On Wed, Jun 20, 2018 at 10:03:30AM -0700, Bart Van Assche wrote:
> Hello Chris and Josef,
>
> The three patches in this series address complaints reported by static
> analyzers (gcc + W=1, sparse, smatch). These patches do not change any
> functionality. Please consider these for inclusion in the
On Wed, Jun 20, 2018 at 03:48:42PM +0300, Nikolay Borisov wrote:
> Overall this series is a win both in code density as well as stack usage and
> brings us closer to completely eliminating the chaotic spread ot fs_info in
> the code base.
The fs_info provided by the transaction handle is a
On Wed, Jun 20, 2018 at 02:36:35PM +0800, Qu Wenruo wrote:
> I see mainline kernel merged commit f8f84b2dfda5 ("btrfs: index
> check-integrity state hash by a dev_t"), and you reviewed it but I can't
> find the mail in mail list, nor it's signed by David.
>
> Is this btrfs related commit merged
On 2018年06月21日 21:58, David Sterba wrote:
> On Wed, Jun 20, 2018 at 03:38:58PM +0800, Qu Wenruo wrote:
>> Commit f8f84b2dfda5 ("btrfs: index check-integrity state hash by a dev_t")
>> changed how btrfsic how we index device state hash.
>>
>> Now we need to access device->bdev->bd_dev, while for
On 21.06.2018 17:02, Qu Wenruo wrote:
>
>
> On 2018年06月21日 21:58, David Sterba wrote:
>> On Wed, Jun 20, 2018 at 03:38:58PM +0800, Qu Wenruo wrote:
>>> Commit f8f84b2dfda5 ("btrfs: index check-integrity state hash by a dev_t")
>>> changed how btrfsic how we index device state hash.
>>>
>>>
On Thu, Jun 21, 2018 at 09:45:00AM +0300, Nikolay Borisov wrote:
> The v0 compat code was introduced in commit 5d4f98a28c7d
> ("Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)") 9
> years ago, which was merged in 2.6.31. This means that the code is
> there to support filesystems which
On Wed, Jun 20, 2018 at 10:03:31AM -0700, Bart Van Assche wrote:
> if (list_empty(>dirty_list)) {
> list_add_tail(>dirty_list,
> >transaction->dirty_bgs);
> - trans->transaction->num_dirty_bgs++;
>
On 20 Jun 2018, at 15:33, David Sterba wrote:
On Wed, Jun 20, 2018 at 07:56:10AM -0700, Chris Mason wrote:
We've been hunting the root cause of data crc errors here at FB for a
while.
We'd find one or two corrupted files, usually displaying crc errors
without any
corresponding IO errors
On 21 Jun 2018, at 5:22, David Sterba wrote:
On Thu, Jun 21, 2018 at 09:45:00AM +0300, Nikolay Borisov wrote:
The v0 compat code was introduced in commit 5d4f98a28c7d
("Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)") 9
years ago, which was merged in 2.6.31. This means that
On Tue, Jun 19, 2018 at 2:38 PM, David Sterba wrote:
> On Mon, Jun 11, 2018 at 07:24:16PM +0100, fdman...@kernel.org wrote:
>> From: Filipe Manana
>>
>> If we failed during a rename exchange operation after starting/joining a
>> transaction, we would end up replacing the return value, stored in
On Wed, Jun 20, 2018 at 12:03 PM, Qu Wenruo wrote:
>
>
> On 2018年06月20日 17:33, Filipe Manana wrote:
>> On Wed, Jun 20, 2018 at 10:22 AM, Qu Wenruo wrote:
>>>
>>>
>>> On 2018年06月20日 17:13, Filipe Manana wrote:
On Fri, Jun 15, 2018 at 2:35 AM, Qu Wenruo wrote:
> [BUG]
> Under certain
On Wed, Jun 06, 2018 at 03:41:49PM +0800, Qu Wenruo wrote:
> We used to call btrfs_file_extent_inline_len() to get the uncompressed
> data size of an inlined extent.
>
> However this function is hiding evil, for compressed extent, it has no
> choice but to directly read out ram_bytes from
On 2018年06月20日 20:48, Nikolay Borisov wrote:
> Hello,
>
> This series aims at removing all the redundant btrfs_fs_info args being
> passed to functions in extent-tree.c. Each patch removes the arg from a
> one function hence it should be fairly easy to review each one of those
> patches.
On Mon, Jun 18, 2018 at 02:13:19PM +0300, Nikolay Borisov wrote:
> When a new extent buffer is allocated there are a few mandatory fields
> which need to be set in order for the buffer to be sane: level,
> generation, bytenr, backref_rev, owner and FSID/UUID. Currently this
> is open coded in the
tree: https://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git
blk-iolatency-v5
head: 9ca920cdc56987426bfc77c18dbfff9d99f242e3
commit: 9ca920cdc56987426bfc77c18dbfff9d99f242e3 [14/14] skip readahead if the
cgroup is congested
config: i386-tinyconfig (attached as .config)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git
blk-iolatency-v5
head: 9ca920cdc56987426bfc77c18dbfff9d99f242e3
commit: 9ca920cdc56987426bfc77c18dbfff9d99f242e3 [14/14] skip readahead if the
cgroup is congested
config: x86_64-randconfig-x013-201824 (attached as
On 06/21/2018 04:39 PM, Nikolay Borisov wrote:
Currently the function uses 2 goto labels to properly handle allocation
failures. This could be simplified by simply re-arranging the code so
that allocations are the in the beginning of the function. This allows
to use simple return statements.
According to this:
https://stratis-storage.github.io/StratisSoftwareDesign.pdf
Page 4 , section 1.2
It claims that BTRFS still have significant technical issues that may
never be resolved.
Could someone shed some light on exactly what these technical issues
might be?! What are BTRFS biggest
On Thu, Jun 21, 2018 at 5:13 PM, waxhead wrote:
> According to this:
>
> https://stratis-storage.github.io/StratisSoftwareDesign.pdf
> Page 4 , section 1.2
>
> It claims that BTRFS still have significant technical issues that may never
> be resolved.
> Could someone shed some light on exactly
Currently, when encoutering -ERANGE in btrfs_get_acl(),
just set acl to NULL so that we cannot get proper
acl information but the operation looks successful.
This patch treats -ERANGE as an error case and meanwhile
print real errno before translating errno to -EIO.
Signed-off-by: Chengguang Xu
For easier debug, print eb->start if level is invalid.
Also make print clear if bytenr found is not expected.
Signed-off-by: Su Yue
---
fs/btrfs/disk-io.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index
On 2018年06月22日 00:34, Filipe Manana wrote:
> On Wed, Jun 20, 2018 at 12:03 PM, Qu Wenruo wrote:
>>
>>
>> On 2018年06月20日 17:33, Filipe Manana wrote:
>>> On Wed, Jun 20, 2018 at 10:22 AM, Qu Wenruo wrote:
On 2018年06月20日 17:13, Filipe Manana wrote:
> On Fri, Jun 15, 2018 at
On 22.06.2018 02:13, waxhead wrote:
> According to this:
>
> https://stratis-storage.github.io/StratisSoftwareDesign.pdf
> Page 4 , section 1.2
>
> It claims that BTRFS still have significant technical issues that may
> never be resolved.
> Could someone shed some light on exactly what these
[BUG]
Under certain KVM load and LTP tests, we are possible to hit the
following calltrace if quota is enabled:
--
BTRFS critical (device vda2): unable to find logical 8820195328 length 4096
BTRFS critical (device vda2): unable to find logical 8820195328 length 4096
[ cut here
The v0 compat code was introduced in commit 5d4f98a28c7d
("Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)") 9
years ago, which was merged in 2.6.31. This means that the code is
there to support filesystems which are _VERY_ old and if you are using
btrfs on such an old kernel, you
33 matches
Mail list logo
