orker/u16:20 Not tainted
5.12.0-0.rc6.184.fc35.x86_64+debug #1
[ 3238.380660] Hardware name: Apple Inc.
MacBookPro8,2/Mac-94245A3940C91C80, BIOS
MBP81.88Z.0050.B00.1804101331 04/10/18
[ 3238.380663] Workqueue: btrfs-delalloc btrfs_work_helper
[ 3238.380670] Call Trace:
[ 3238.380674] dump_stack+0x7f
include Omar Sandoval.
robbieko 於 2017-10-26 14:02 寫到:
From: Robbie Ko
Found it when test btrfs delalloc accounting overflow, Fix offset
error.
We will fill in the gaps between the created extents,
then outstanding extents will all be merged into 1.
Signed-off-by: Robbie Ko
---
tests
From: Robbie Ko
Found it when test btrfs delalloc accounting overflow, Fix offset error.
We will fill in the gaps between the created extents,
then outstanding extents will all be merged into 1.
Signed-off-by: Robbie Ko
---
tests/btrfs/010 | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On Wed, Jun 07, 2017 at 10:34:13AM -0700, Omar Sandoval wrote:
> On Wed, Jun 07, 2017 at 05:36:45PM +0800, Eryu Guan wrote:
> > On Tue, Jun 06, 2017 at 11:57:10PM -0700, Omar Sandoval wrote:
> > > From: Omar Sandoval
> > >
> > > This is a regression test for "[PATCH] Btrfs: fix delalloc accountin
On Wed, Jun 07, 2017 at 05:36:45PM +0800, Eryu Guan wrote:
> On Tue, Jun 06, 2017 at 11:57:10PM -0700, Omar Sandoval wrote:
> > From: Omar Sandoval
> >
> > This is a regression test for "[PATCH] Btrfs: fix delalloc accounting
> > leak caused by u32 overflow". It creates a bunch of delalloc extent
On Tue, Jun 06, 2017 at 11:57:10PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> This is a regression test for "[PATCH] Btrfs: fix delalloc accounting
> leak caused by u32 overflow". It creates a bunch of delalloc extents and
> merges them together to make sure the accounting is done righ
From: Omar Sandoval
This is a regression test for "[PATCH] Btrfs: fix delalloc accounting
leak caused by u32 overflow". It creates a bunch of delalloc extents and
merges them together to make sure the accounting is done right.
Signed-off-by: Omar Sandoval
---
tests/btrfs/010 | 75 +
On Wed, Jun 07, 2017 at 11:08:01AM +0800, Eryu Guan wrote:
> On Tue, Jun 06, 2017 at 05:03:05PM -0700, Omar Sandoval wrote:
> > On Sat, Jun 03, 2017 at 12:37:00AM -0700, Christoph Hellwig wrote:
> > > This looks like a btrfs-specific test, and not like a generic one
> > > to me.
> >
> > Nothing ab
On Tue, Jun 06, 2017 at 05:03:05PM -0700, Omar Sandoval wrote:
> On Sat, Jun 03, 2017 at 12:37:00AM -0700, Christoph Hellwig wrote:
> > This looks like a btrfs-specific test, and not like a generic one
> > to me.
>
> Nothing about the workload itself is btrfs-specific, we just have the
> extra che
On Sat, Jun 03, 2017 at 12:37:00AM -0700, Christoph Hellwig wrote:
> This looks like a btrfs-specific test, and not like a generic one
> to me.
Nothing about the workload itself is btrfs-specific, we just have the
extra check at the end. But I don't really care, I can make it a btrfs
test unless E
This looks like a btrfs-specific test, and not like a generic one
to me.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jun 02, 2017 at 02:46:52PM +0200, David Sterba wrote:
> On Fri, Jun 02, 2017 at 12:07:37PM +0300, Nikolay Borisov wrote:
> > > +# Make sure that we didn't leak any metadata space.
> > > +if [[ $FSTYP = btrfs ]]; then
> > > + uuid="$(findmnt -n -o UUID "$TEST_DIR")"
> >
> > if we are on btr
On Fri, Jun 02, 2017 at 12:07:37PM +0300, Nikolay Borisov wrote:
> > +# Make sure that we didn't leak any metadata space.
> > +if [[ $FSTYP = btrfs ]]; then
> > + uuid="$(findmnt -n -o UUID "$TEST_DIR")"
>
> if we are on btrfs and we don't have findmnt this test will likely fail.
> Perhaps inclu
On 2.06.2017 11:23, Omar Sandoval wrote:
> From: Omar Sandoval
>
> This is a regression test for "[PATCH] Btrfs: fix delalloc accounting
> leak caused by u32 overflow". It creates a bunch of delalloc extents and
> merges them together to make sure the accounting is done right.
>
> Signed-off-
From: Omar Sandoval
This is a regression test for "[PATCH] Btrfs: fix delalloc accounting
leak caused by u32 overflow". It creates a bunch of delalloc extents and
merges them together to make sure the accounting is done right.
Signed-off-by: Omar Sandoval
---
tests/generic/438 | 77 +++
We encountered an issue that was easily observable on s/390 systems but
could really happen anywhere. The timing just seemed to hit reliably
on s/390 with limited memory.
The gist is that when an unexpected set_page_dirty() happened, we'd
run into the BUG() in btrfs_writepage_fixup_worker since it
am running, I saw
>> > btfs-delalloc taking about 1 CPU worth of time, much as could be
>> > expected. I then started up 2 programs at the same time, writing data
>> > to the BTRFS volume. btrfs-delalloc still only used 1 CPU worth of
>> > time. Is btrfs-delal
t 1 CPU worth of time, much as could be
> > expected. I then started up 2 programs at the same time, writing data
> > to the BTRFS volume. btrfs-delalloc still only used 1 CPU worth of
> > time. Is btrfs-delalloc threaded, to where it can use more than 1 CPU
> > worth
at the same time, writing data
> to the BTRFS volume. btrfs-delalloc still only used 1 CPU worth of
> time. Is btrfs-delalloc threaded, to where it can use more than 1 CPU
> worth of time? Is there a threshold where it would start using more
> CPU?
[...]
Hiya,
I observe the same h
. btrfs-delalloc still only used 1 CPU worth of
time. Is btrfs-delalloc threaded, to where it can use more than 1 CPU
worth of time? Is there a threshold where it would start using more
CPU?
Thanks for any information you can provide.
--
Andy Carlson
On 07/01/2011 06:07 PM, Josef Bacik wrote:
I found what my btrfs partition now is really slow. Something wrong
happend. I try on 2.6.32 and 2.6.39 - same result. It is because
partition is almost full?
I run a simple cycle to clean some old files:
for i in `cat /tmp/delit`; do rm -f $i ; done
On 07/01/2011 03:11 AM, Proskurin Kirill wrote:
> On 06/30/2011 09:13 PM, Josef Bacik wrote:
>> On 06/30/2011 10:12 AM, Proskurin Kirill wrote:
>>> On 06/29/2011 08:14 PM, Josef Bacik wrote:
> Ok - I upgrade to 2.6.39-2 but it is seems to all things get worse.
> Now I see [btrfs-transacti]&
On 06/30/2011 09:13 PM, Josef Bacik wrote:
> On 06/30/2011 10:12 AM, Proskurin Kirill wrote:
>> On 06/29/2011 08:14 PM, Josef Bacik wrote:
Ok - I upgrade to 2.6.39-2 but it is seems to all things get worse.
Now I see [btrfs-transacti]& btrfs-endio-wri] 80-100% all the
time and
i
On 06/30/2011 09:13 PM, Josef Bacik wrote:
On 06/30/2011 10:12 AM, Proskurin Kirill wrote:
On 06/29/2011 08:14 PM, Josef Bacik wrote:
Ok - I upgrade to 2.6.39-2 but it is seems to all things get worse.
Now I see [btrfs-transacti]& btrfs-endio-wri] 80-100% all the time and
io performance looks
On 06/30/2011 09:13 PM, Josef Bacik wrote:
On 06/30/2011 10:12 AM, Proskurin Kirill wrote:
On 06/29/2011 08:14 PM, Josef Bacik wrote:
Ok - I upgrade to 2.6.39-2 but it is seems to all things get worse.
Now I see [btrfs-transacti]& btrfs-endio-wri] 80-100% all the time and
io performance looks
On 06/30/2011 10:12 AM, Proskurin Kirill wrote:
> On 06/29/2011 08:14 PM, Josef Bacik wrote:
>>> Ok - I upgrade to 2.6.39-2 but it is seems to all things get worse.
>>> Now I see [btrfs-transacti]& btrfs-endio-wri] 80-100% all the time and
>>> io performance looks like lower then before.
>>>
>>> O
s on mdadm RAID5 with 8 HDD - 27T partition.
>>>
>>> I see this at top:
>>> 1182 root 20 0 000 R 100.0 0.0 16:39.73
>>> [btrfs-delalloc-]
>>>
>>> And LA is grow. What is this and how can I fix it?
>>
>> delalloc
:39.73
[btrfs-delalloc-]
And LA is grow. What is this and how can I fix it?
delalloc is a delayed allocation kernel thread -- it probably means something
is writing large amounts of data to the file system
2.6.32 is *old* as far as btrfs is concerned, there have been many bugs fixed
and performance
On Monday 27 of June 2011 11:04:06 Proskurin Kirill wrote:
> Hello all.
>
> What we have:
> SL6 - kernel 2.6.32-131.2.1.el6.x86_64
> btrfs on mdadm RAID5 with 8 HDD - 27T partition.
>
> I see this at top:
> 1182 root 20 0 000 R 100.0 0.0 16:39.73
>
Hello all.
What we have:
SL6 - kernel 2.6.32-131.2.1.el6.x86_64
btrfs on mdadm RAID5 with 8 HDD - 27T partition.
I see this at top:
1182 root 20 0 000 R 100.0 0.0 16:39.73
[btrfs-delalloc-]
And LA is grow. What is this and how can I fix it?
--
Best regards,
Proskurin
30 matches
Mail list logo
