On 2018/10/9 上午6:41, Chris Murphy wrote:
> [chris@flap ~]$ sudo perf stat -e 'btrfs:*' -a sleep 70
> ##And then I loaded a few sites in Firefox early on in those 70 seconds.
>
> Performance counter stats for 'system wide':
>
> 5 btrfs:btrfs_transaction_commit
>
On 10/8/18 8:30 PM, Qu Wenruo wrote:
Unlike lowmem mode check, we don't have good place for original mode to
check overlap dev extents.
So this patch introduces a new function, btrfs_check_dev_extents(), to
handle possible bad dev extents.
Reported-by: Hans van Kranenburg
Signed-off-by: Qu
On 10/8/18 8:30 PM, Qu Wenruo wrote:
Add such check at check_dev_item(), since at that timing we're also
iterating dev extents for dev item accounting.
Signed-off-by: Qu Wenruo
LGTM.
Reviewed-by: Su Yue
---
check/mode-lowmem.c | 34 --
1 file changed,
On 2018/10/9 上午6:20, Hans van Kranenburg wrote:
> On 10/08/2018 02:30 PM, Qu Wenruo wrote:
>> Obviously, used bytes can't be larger than total bytes.
>>
>> Signed-off-by: Qu Wenruo
>> ---
>> check/mode-lowmem.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git
On 10/09/2018 02:08 AM, Nicholas D Steeves wrote:
> On Mon, Oct 08, 2018 at 04:10:55PM +, Hugo Mills wrote:
>> On Mon, Oct 08, 2018 at 03:49:53PM +0200, Pierre Couderc wrote:
>>> I ma trying to make a "RAID1" with /dev/sda2 ans /dev/sdb (or similar).
>>>
>>> But I have stranges status or
On Mon, Oct 08, 2018 at 04:10:55PM +, Hugo Mills wrote:
> On Mon, Oct 08, 2018 at 03:49:53PM +0200, Pierre Couderc wrote:
> > I ma trying to make a "RAID1" with /dev/sda2 ans /dev/sdb (or similar).
> >
> > But I have stranges status or errors about "missing devices" and I
> > do not
On 10/08/2018 03:19 PM, Hans van Kranenburg wrote:
> On 10/08/2018 08:43 AM, Qu Wenruo wrote:
>>
>>
>> On 2018/10/5 下午6:58, Hans van Kranenburg wrote:
>>> On 10/05/2018 09:51 AM, Qu Wenruo wrote:
On 2018/10/5 上午5:24, Hans van Kranenburg wrote:
> This patch set contains an
We have a known bug in btrfs, that we let the device path be changed
after the device has been mounted. So using this loop hole the new
copied device would appears as if its mounted immediately after its
been copied. So this test case reproduces this issue.
For example:
Initially..
[chris@flap ~]$ sudo perf stat -e 'btrfs:*' -a sleep 70
##And then I loaded a few sites in Firefox early on in those 70 seconds.
Performance counter stats for 'system wide':
5 btrfs:btrfs_transaction_commit
29 btrfs:btrfs_inode_new
29
On 10/08/2018 02:30 PM, Qu Wenruo wrote:
> Obviously, used bytes can't be larger than total bytes.
>
> Signed-off-by: Qu Wenruo
> ---
> check/mode-lowmem.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/check/mode-lowmem.c b/check/mode-lowmem.c
> index 07c03cad77af..1173b963b8f3
On 10/08/2018 11:21 PM, Hugo Mills wrote:
On Mon, Oct 08, 2018 at 11:01:35PM +0200, Pierre Couderc wrote:
On 10/08/2018 06:14 PM, Hugo Mills wrote:
On Mon, Oct 08, 2018 at 04:10:55PM +, Hugo Mills wrote:
On Mon, Oct 08, 2018 at 03:49:53PM +0200, Pierre Couderc wrote:
I ma trying to
On Mon, Oct 08, 2018 at 11:01:35PM +0200, Pierre Couderc wrote:
> On 10/08/2018 06:14 PM, Hugo Mills wrote:
> >On Mon, Oct 08, 2018 at 04:10:55PM +, Hugo Mills wrote:
> >>On Mon, Oct 08, 2018 at 03:49:53PM +0200, Pierre Couderc wrote:
> >>>I ma trying to make a "RAID1" with /dev/sda2 ans
On 10/08/2018 06:37 PM, Holger Hoffstätte wrote:
> On 10/08/18 17:46, Hans van Kranenburg wrote:
>
>> fs.devices() also looks for dev_items in the chunk tree:
>>
>> https://github.com/knorrie/python-btrfs/blob/master/btrfs/ctree.py#L481
>>
>> So, BOOM! you need root.
>>
>> Or just start a 0,
On 10/06/2018 06:14 PM, Eryu Guan wrote:
On Mon, Oct 01, 2018 at 04:44:35PM +0800, Anand Jain wrote:
We have a known bug in btrfs, that we let the device path be changed
after the device has been mounted. So using this loop hole the new
copied device would appears as if its mounted
We have a known bug in btrfs, that we let the device path be changed
after the device has been mounted. So using this loop hole the new
copied device would appears as if its mounted immediately after its
been copied. So this test case reproduces this issue.
For example:
Initially..
On 10/08/18 17:46, Hans van Kranenburg wrote:
fs.devices() also looks for dev_items in the chunk tree:
https://github.com/knorrie/python-btrfs/blob/master/btrfs/ctree.py#L481
So, BOOM! you need root.
Or just start a 0, ignore errors and start trying all devids until you
found num_devices
On Mon, Oct 08, 2018 at 04:10:55PM +, Hugo Mills wrote:
> On Mon, Oct 08, 2018 at 03:49:53PM +0200, Pierre Couderc wrote:
> > I ma trying to make a "RAID1" with /dev/sda2 ans /dev/sdb (or similar).
> >
> > But I have stranges status or errors about "missing devices" and I
> > do not
On Mon, Oct 08, 2018 at 03:49:53PM +0200, Pierre Couderc wrote:
> I ma trying to make a "RAID1" with /dev/sda2 ans /dev/sdb (or similar).
>
> But I have stranges status or errors about "missing devices" and I
> do not understand the current situation :
>
>
> root@server:~# btrfs fi show
>
On 10/08/2018 05:29 PM, Holger Hoffstätte wrote:
> On 10/08/18 16:40, Hans van Kranenburg wrote:
>>> Looking at the kernel side of things in fs/btrfs/ioctl.c I see both
>>> BTRFS_IOC_TREE_SEARCH[_V2} unconditionally require CAP_SYS_ADMIN.
>>
>> That's the tree search ioctl, for reading arbitrary
On 10/08/18 16:40, Hans van Kranenburg wrote:
Looking at the kernel side of things in fs/btrfs/ioctl.c I see both
BTRFS_IOC_TREE_SEARCH[_V2} unconditionally require CAP_SYS_ADMIN.
That's the tree search ioctl, for reading arbitrary metadata.
The device stats ioctl is IOC_GET_DEV_STATS...
On 10/08/2018 04:40 PM, Hans van Kranenburg wrote:
> On 10/08/2018 04:27 PM, Holger Hoffstätte wrote:
>> (moving the discussion here from GH [1])
>>
>> Apparently there is something weird going on with the device stats
>> ioctls. I cannot get them to work as regular user, while they work
>> for
On 15:03 08/10, David Sterba wrote:
> On Fri, Oct 05, 2018 at 07:26:15AM -0500, Goldwyn Rodrigues wrote:
> > Code cleanup.
>
> Have you check when and why the variable become unused? Thanks.
No, I did not check it earlier. git blame points to
312c89fbca06 ("btrfs: cleanup btrfs_mount() using
On 10/08/2018 04:27 PM, Holger Hoffstätte wrote:
> (moving the discussion here from GH [1])
>
> Apparently there is something weird going on with the device stats
> ioctls. I cannot get them to work as regular user, while they work
> for David. A friend confirms the same issue on his system - no
(moving the discussion here from GH [1])
Apparently there is something weird going on with the device stats
ioctls. I cannot get them to work as regular user, while they work
for David. A friend confirms the same issue on his system - no access
as non-root.
So I made a new empty fs, mounted it,
I ma trying to make a "RAID1" with /dev/sda2 ans /dev/sdb (or similar).
But I have stranges status or errors about "missing devices" and I do
not understand the current situation :
root@server:~# btrfs fi show
Label: none uuid: 28c2b7ab-631c-40a3-bab7-00dac5dd20eb
Total devices 1
On Fri, Sep 28, 2018 at 07:18:03AM -0400, Josef Bacik wrote:
> I ran into an issue where there was some reference being held on an
> inode that I couldn't track. This assert wasn't triggered, but it at
> least rules out we're doing something stupid.
>
> Reviewed-by: Omar Sandoval
>
On Fri, Sep 28, 2018 at 07:18:02AM -0400, Josef Bacik wrote:
> Allocating new chunks modifies both the extent and chunk tree, which can
> trigger new chunk allocations. So instead of doing list_for_each_safe,
> just do while (!list_empty()) so we make sure we don't exit with other
> pending bg's
On Fri, Oct 05, 2018 at 07:26:15AM -0500, Goldwyn Rodrigues wrote:
> Code cleanup.
Have you check when and why the variable become unused? Thanks.
Now two locations can detect such problem, either by device item
used/total bytes check, or by early dev extents check against device
boundary.
The image is hand-crafted image which uses DATA SINGLE chunk to feed
btrfs check.
As expected, as long as block group item, chunk item, device used bytes
Unlike lowmem mode check, we don't have good place for original mode to
check overlap dev extents.
So this patch introduces a new function, btrfs_check_dev_extents(), to
handle possible bad dev extents.
Reported-by: Hans van Kranenburg
Signed-off-by: Qu Wenruo
---
check/main.c | 99
Obviously, used bytes can't be larger than total bytes.
Signed-off-by: Qu Wenruo
---
check/mode-lowmem.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/check/mode-lowmem.c b/check/mode-lowmem.c
index 07c03cad77af..1173b963b8f3 100644
--- a/check/mode-lowmem.c
+++ b/check/mode-lowmem.c
Add such check at check_dev_item(), since at that timing we're also
iterating dev extents for dev item accounting.
Signed-off-by: Qu Wenruo
---
check/mode-lowmem.c | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/check/mode-lowmem.c
When restoring btrfs image, the total_bytes of device item is not
updated correctly. In fact total_bytes can be left 0 for restored image.
It doesn't trigger any error because btrfs check never checks
total_bytes of dev item.
However this is going to change.
Fix it by populating total_bytes of
Signed-off-by: Qu Wenruo
---
check/main.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/check/main.c b/check/main.c
index ff9a785ce555..12f12e18a83f 100644
--- a/check/main.c
+++ b/check/main.c
@@ -7938,6 +7938,12 @@ static int check_device_used(struct device_record
*dev_rec,
This patchset can be fetch from github:
https://github.com/adam900710/btrfs-progs/tree/dev_extents_check
Hans van Kranenburg reported a case where btrfs DUP chunk allocator
could allocate invalid dev extents, either overlaps with existing dev
extents or beyond device boundary.
This patchset
On 2018-10-07 09:37, Holger Hoffstätte wrote:
The Prometheus statistics collection/aggregation/monitoring/alerting system
[1] is quite popular, easy to use and will probably be the basis for the
upcoming OpenMetrics "standard" [2].
Prometheus collects metrics by polling host-local "exporters"
On 2018-10-05 20:34, Duncan wrote:
Wilson, Ellis posted on Fri, 05 Oct 2018 15:29:52 + as excerpted:
Is there any tuning in BTRFS that limits the number of outstanding reads
at a time to a small single-digit number, or something else that could
be behind small queue depths? I can't
On Fri, Sep 28, 2018 at 12:21 PM Josef Bacik wrote:
>
> The cleaner thread usually takes care of delayed iputs, with the
> exception of the btrfs_end_transaction_throttle path. The cleaner
> thread only gets woken up every 30 seconds, so instead wake it up to do
> it's work so that we can free
Signed-off-by: Qu Wenruo
---
check/main.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/check/main.c b/check/main.c
index ff9a785ce555..12f12e18a83f 100644
--- a/check/main.c
+++ b/check/main.c
@@ -7938,6 +7938,12 @@ static int check_device_used(struct device_record
*dev_rec,
Obviously, used bytes can't be larger than total bytes.
Signed-off-by: Qu Wenruo
---
check/mode-lowmem.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/check/mode-lowmem.c b/check/mode-lowmem.c
index 07c03cad77af..1173b963b8f3 100644
--- a/check/mode-lowmem.c
+++ b/check/mode-lowmem.c
Now two locations can detect such problem, either by device item
used/total bytes check, or by early dev extents check against device
boundary.
The image is hand-crafted image which uses DATA SINGLE chunk to feed
btrfs check.
As expected, as long as block group item, chunk item, device used bytes
Add such check at check_dev_item(), since at that timing we're also
iterating dev extents for dev item accounting.
Signed-off-by: Qu Wenruo
---
check/mode-lowmem.c | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/check/mode-lowmem.c
Unlike lowmem mode check, we don't have good place for original mode to
check overlap dev extents.
So this patch introduces a new function, btrfs_check_dev_extents(), to
handle possible bad dev extents.
Reported-by: Hans van Kranenburg
Signed-off-by: Qu Wenruo
---
check/main.c | 99
This patchset can be fetch from github:
https://github.com/adam900710/btrfs-progs/tree/dev_extents_check
Hans van Kranenburg reported a case where btrfs DUP chunk allocator
could allocate invalid dev extents, either overlaps with existing dev
extents or beyond device boundary.
This patchset
From: Filipe Manana
When replaying a log which contains a tmpfile (which necessarily has a
link count of 0) we end up calling inc_nlink(), at
fs/btrfs/tree-log.c:replay_one_buffer(), which produces a warning like
the following:
[195191.943673] WARNING: CPU: 0 PID: 6924 at fs/inode.c:342
On 2018/10/8 下午5:28, Su Yue wrote:
>
>
> On 10/8/18 3:00 PM, Qu Wenruo wrote:
>> Add such check at check_dev_item(), since at that timing we're also
>> iterating dev extents for dev item accounting.
>>
>> Signed-off-by: Qu Wenruo
>> ---
>> check/mode-lowmem.c | 32
From: Filipe Manana
Test that if we fsync a tmpfile, without adding a hard link to it, and
then power fail, we will be able to mount the filesystem without
triggering any crashes, warnings or corruptions.
This test is motivated by an issue in btrfs where this scenario triggered
a warning
On 10/8/18 3:00 PM, Qu Wenruo wrote:
Add such check at check_dev_item(), since at that timing we're also
iterating dev extents for dev item accounting.
Signed-off-by: Qu Wenruo
---
check/mode-lowmem.c | 32 ++--
1 file changed, 30 insertions(+), 2 deletions(-)
On 10/8/18 3:00 PM, Qu Wenruo wrote:
Now two locations can detect such problem, either by device item
used/total bytes check, or by early dev extents check against device
boundary.
The image is hand-crafted image which uses DATA SINGLE chunk to feed
btrfs check.
As expected, as long as block
Signed-off-by: Qu Wenruo
---
check/main.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/check/main.c b/check/main.c
index ff9a785ce555..12f12e18a83f 100644
--- a/check/main.c
+++ b/check/main.c
@@ -7938,6 +7938,12 @@ static int check_device_used(struct device_record
*dev_rec,
Unlike lowmem mode check, we don't have good place for original mode to
check overlap dev extents.
So this patch introduces a new function, btrfs_check_dev_extents(), to
handle possible bad dev extents.
Reported-by: Hans van Kranenburg
Signed-off-by: Qu Wenruo
---
check/main.c | 99
Obviously, used bytes can't be larger than total bytes.
Signed-off-by: Qu Wenruo
---
check/mode-lowmem.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/check/mode-lowmem.c b/check/mode-lowmem.c
index d387423639e6..c50e34236ac8 100644
--- a/check/mode-lowmem.c
+++ b/check/mode-lowmem.c
Now two locations can detect such problem, either by device item
used/total bytes check, or by early dev extents check against device
boundary.
The image is hand-crafted image which uses DATA SINGLE chunk to feed
btrfs check.
As expected, as long as block group item, chunk item, device used bytes
Add such check at check_dev_item(), since at that timing we're also
iterating dev extents for dev item accounting.
Signed-off-by: Qu Wenruo
---
check/mode-lowmem.c | 32 ++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/check/mode-lowmem.c
This patchset can be fetch from github:
https://github.com/adam900710/btrfs-progs/tree/dev_extents_check
Hans van Kranenburg reported a case where btrfs DUP chunk allocator
could allocate invalid dev extents, either overlaps with existing dev
extents or beyond device boundary.
This patchset
On 2018/10/5 下午6:58, Hans van Kranenburg wrote:
> On 10/05/2018 09:51 AM, Qu Wenruo wrote:
>>
>>
>> On 2018/10/5 上午5:24, Hans van Kranenburg wrote:
>>> This patch set contains an additional fix for a newly exposed bug after
>>> the previous attempt to fix a chunk allocator bug for new DUP
56 matches
Mail list logo
