On Mon, Aug 22, 2016 at 04:06:13PM -0700, Darrick J. Wong wrote:
> [add Dave and Christoph to cc]
>
> On Mon, Aug 22, 2016 at 04:14:19PM -0400, Jeff Mahoney wrote:
> > On 8/21/16 2:59 PM, Tomokhov Alexander wrote:
> > > Btrfs wiki FAQ gives a link to example Python script:
> > > https://github.co
On Mon, Aug 22, 2016 at 5:06 PM, Darrick J. Wong
wrote:
> [add Dave and Christoph to cc]
>
> On Mon, Aug 22, 2016 at 04:14:19PM -0400, Jeff Mahoney wrote:
>> On 8/21/16 2:59 PM, Tomokhov Alexander wrote:
>> > Btrfs wiki FAQ gives a link to example Python script:
>> > https://github.com/stsquad/sc
On Mon, Aug 22, 2016 at 6:26 PM, Jeff Mahoney wrote:
> On 8/22/16 6:51 PM, Chris Murphy wrote:
>> Trivially reproducible every boot, shortly after mount happens. Also
>> happened with rc2.
>>
>
> Yep. We've disabled this in our kernels. It can actually deadlock.
Interesting. I've only gotten sc
On 8/22/16 6:51 PM, Chris Murphy wrote:
> Trivially reproducible every boot, shortly after mount happens. Also
> happened with rc2.
>
Yep. We've disabled this in our kernels. It can actually deadlock.
-Jeff
>
> [ 13.225891] virbr0: port 1(virbr0-nic) entered blocking state
> [ 13.225895]
Thanks for the in-depth answer.
Well, "simple enough process" is still a sequence of steps which must be
carefully done. In a proper order with correct parameters depending on
environment. It's work with data, data which can be invaluable.
No, really, I'm not a beginner user. I use Arch Linux ev
Oh, didn't know that XFS is going to have many of Btrfs features and continues
to evolve. Thank you for the answer.
22.08.2016, 23:14, "Jeff Mahoney" :
> On 8/21/16 2:59 PM, Tomokhov Alexander wrote:
>> Btrfs wiki FAQ gives a link to example Python script:
>> https://github.com/stsquad/scripts/
[add Dave and Christoph to cc]
On Mon, Aug 22, 2016 at 04:14:19PM -0400, Jeff Mahoney wrote:
> On 8/21/16 2:59 PM, Tomokhov Alexander wrote:
> > Btrfs wiki FAQ gives a link to example Python script:
> > https://github.com/stsquad/scripts/blob/master/uncow.py
> >
> > But such a crucial and fundam
Trivially reproducible every boot, shortly after mount happens. Also
happened with rc2.
[ 13.225891] virbr0: port 1(virbr0-nic) entered blocking state
[ 13.225895] virbr0: port 1(virbr0-nic) entered listening state
[ 13.299806] virbr0: port 1(virbr0-nic) entered disabled state
[ 13.3091
Em Seg, 2016-08-22 às 14:49 -0600, Chris Murphy escreveu:
> This is really weird. I'm running 4.7.0 (Fedora) and I'm not
> experiencing problems, let alone this. What is this kernel's
> provenance? Is it a plain mainline 4.7.0 that you built? I'm not
> really sure what to recommend except maybe goi
On Mon, Aug 22, 2016 at 2:39 PM, Ronan Arraes Jardim Chagas
wrote:
> The same thing just happened again! And now it was also fixed
> automatically, but now I have:
>
> Metadata,DUP: Size:33.50GiB, Used:812.78MiB
This is really weird. I'm running 4.7.0 (Fedora) and I'm not
experiencing problems, l
The same thing just happened again! And now it was also fixed
automatically, but now I have:
Metadata,DUP: Size:33.50GiB, Used:812.78MiB
--
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://vg
On 8/21/16 2:59 PM, Tomokhov Alexander wrote:
> Btrfs wiki FAQ gives a link to example Python script:
> https://github.com/stsquad/scripts/blob/master/uncow.py
>
> But such a crucial and fundamental tool must exist in stock btrfs-progs.
> Filesystem with CoW technology at it's core must provide
New information guys! I formatted using the latest Tumbleweed snapshot
(btrfs-progs v4.7+20160729) and I still have the same problem.
I notice two things. First, when I see the "No space left on device",
it is fixed when the Metadata space increases **a lot**. For example,
when the error first occ
Hi Josef,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.8-rc3 next-20160822]
[cannot apply to linux/master]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=a
Provide a mechanism for file systems to indicate how much dirty metadata they
are holding. This introduces a few things
1) Zone stats for dirty metadata, which is the same as the NR_FILE_DIRTY.
2) WB stat for dirty metadata. This way we know if we need to try and call into
the file system to wri
Now that we have metadata counters in the VM, we need to provide a way to kick
writeback on dirty metadata. Introduce super_operations->write_metadata. This
allows file systems to deal with writing back any dirty metadata we need based
on the writeback needs of the system. Since there is no inod
Here is my updated set of patches for providing a way for fs'es to do their own
accounting for their dirty metadata pages. The changes since V1 include
-Split the accounting + ->write_metadata patches out into their own patches.
-Added a few more account_metadata* helpers that I hadn't thought ab
The only reason we pass in the mapping is to get the inode in order to see if
writeback cgroups is enabled, and even then it only checks the bdi and a super
block flag. balance_dirty_pages() doesn't even use the mapping. Since
balance_dirty_pages*() works on a bdi level, just pass in the bdi and
On Mon, Aug 22 2016 at 4:05am -0400,
Lukas Herbolt wrote:
> Hello,
>
> There is patch from Mike. It's part of current pull request to 4.8-rc1
> For more details check:
> - https://www.redhat.com/archives/dm-devel/2016-July/msg00561.html
> - https://www.redhat.com/archives/dm-devel/2016-August
Hi Qu,
Sorry for the confusion. Reading the email again and the code it seems
that the READS are really returned as -EIO if you set the drop_writes.
I just tested it and you are right.
If I was reading the fstest correctly the flakey is created as:
---
flakey: 0 409600 flakey 8:64 0 0 180 1 drop_
Hello,
There is patch from Mike. It's part of current pull request to 4.8-rc1
For more details check:
- https://www.redhat.com/archives/dm-devel/2016-July/msg00561.html
- https://www.redhat.com/archives/dm-devel/2016-August/msg00109.html
Lukas
On Mon, Aug 22, 2016 at 9:31 AM, Qu Wenruo wrote:
Hi, Mike and btrfs and dm guys
When doing regression test on v4.8-rc1, we found that fstests/btrfs/056
always fails. With the following dmesg:
---
Buffer I/O error on dev dm-0, logical block 1310704, async page read
Buffer I/O error on dev dm-0, logical block 16, async page read
Buffer I/O erro
22 matches
Mail list logo