Re: Will Btrfs have an official command to "uncow" existing files?

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: > > >

Re: Will Btrfs have an official command to "uncow" existing files?

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: >> >

Re: possible recursive locking detected, 4.8.0-0.rc3.git0.1.fc25.x86_64+debug

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.

Re: possible recursive locking detected, 4.8.0-0.rc3.git0.1.fc25.x86_64+debug

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 > [

Re: Will Btrfs have an official command to "uncow" existing files?

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

Re: Will Btrfs have an official command to "uncow" existing files?

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: >>

Re: Will Btrfs have an official command to "uncow" existing files?

[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

possible recursive locking detected, 4.8.0-0.rc3.git0.1.fc25.x86_64+debug

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 [

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

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

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

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

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

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

Re: Will Btrfs have an official command to "uncow" existing files?

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

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

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

Re: [PATCH 1/3] remove mapping from balance_dirty_pages*()

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

[PATCH 2/3] writeback: allow for dirty metadata accounting

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

[PATCH 3/3] writeback: introduce super_operations->write_metadata

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

[PATCH 0/3][V2] Provide accounting for dirty metadata

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

[PATCH 1/3] remove mapping from balance_dirty_pages*()

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

Re: [Regression/Behavior change]dm-flakey corrupt read bio, even the feature is drop_writes

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 > -

Re: [dm-devel] [Regression/Behavior change]dm-flakey corrupt read bio, even the feature is drop_writes

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

Re: [dm-devel] [Regression/Behavior change]dm-flakey corrupt read bio, even the feature is drop_writes

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

[Regression/Behavior change]dm-flakey corrupt read bio, even the feature is drop_writes

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