Re: Fwd: [Bug 1547319] 4.16.0-0.rc1.git4.1.fc28.x86_64 #1 Not tainted: possible recursive locking detected

list. This is best >> reported to the upstream btrfs devs. > > Quick and wrong conclusions, it's not a btrfs bug. > > The fix: > > https://patchwork.kernel.org/patch/10207013/ > > but I don't see it merged in master branch. Thank you for the reply :) I'll keep my ticket ope

Fwd: [Bug 1547319] 4.16.0-0.rc1.git4.1.fc28.x86_64 #1 Not tainted: possible recursive locking detected

b...@redhat.com> --- This is btrfs which is pretty far down on our priority list. This is best reported to the upstream btrfs devs. -- You are receiving this mail because: You reported the bug. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH -- To unsubscribe from this list: send the

[no subject]

k you" to all those people involved in reaching current state :) kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH -- 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

Re: 4.15.0-0.rc2.git2.1.fc28.x86_64: possible circular locking dependency detected

On 12 December 2017 at 06:50, Chris Murphy <li...@colorremedies.com> wrote: > > On Mon, Dec 11, 2017 at 10:12 PM, Tomasz Kłoczko > <kloczko.tom...@gmail.com> wrote: > > Hi, > > > > Jut done upgrade on my laptop to the latest Fedora rawhide packages. >

4.15.0-0.rc2.git2.1.fc28.x86_64: possible circular locking dependency detected

00 RCX: 7f7e2d309687 [ 94.194849] RDX: 7f7e10ce34b0 RSI: 0001 RDI: 7f7e24ddb000 [ 94.194853] RBP: 7f7e10ce3830 R08: 7f7e10ce34b0 R09: 0400 [ 94.194857] R10: R11: 0206 R12: 7f7e17d18c50 [ 94.194861] R13: 0000561dfbb5d028 R1

Re: [GIT PULL] Btrfs fixes for 4.14-rc4

3d18630 [ 101.328925] R13: 55f10ab6ef48 R14: 0012406e5969 R15: 0001 kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH On 6 October 2017 at 16:34, David Sterba <dste...@suse.com> wrote: > Hi, > > we have two more fixes for bugs introduced in 4.1

[4.14.0-0.rc2.git3.1.fc28.x86_64]: possible circular locking dependency detected

R13: 562b50713f48 R14: 0011d1d47ffa R15: 0001 kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH -- 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

Re: defragmenting best practice?

w glue some number random updates into larger sequential write IOs). kloczek -- Tomasz Kłoczko LinkedIn: http://lnkd.in/FXPWxH -- 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

Re: defragmenting best practice?

s over qemu? Is it anything more running on the host system during those tests? . . . I can probably make this list of questions 2 or 3 times longer. koczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs"

Re: defragmenting best practice?

On 14 September 2017 at 19:53, Austin S. Hemmelgarn wrote: [..] > While it's not for BTRFS< a tool called e4rat might be of interest to you > regarding this. It reorganizes files on an ext4 filesystem so that stuff > used by the boot loader is right at the beginning of the

Re: defragmenting best practice?

On 14 September 2017 at 16:24, Kai Krakow wrote: [..] > Getting e.g. boot files into read order or at least nearby improves > boot time a lot. Similar for loading applications. By how much it is possible to improve boot time? Just please some example which I can try to

Re: defragmenting best practice?

up to now was not written even single line of ZFS code to handle active fragmentation and no one been able to prove that something about active defragmentation needs to be done in case of ZFS. Why? Because all stands on the shoulders of enough cleaver *allocation algorithm*. Only this and nothing mor

Re: test if a subvolume is a snapshot?

stats --format=json / How many people you know who are communicating in json or using comma separated lines of text? Maybe it is not obvious but such interface is not for the humans. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH -- To unsubscribe from this list: send the li

Re: test if a subvolume is a snapshot?

On 8 September 2017 at 17:39, David Sterba wrote: [..] > My plan is to introduce a global options to set various this, also the > output format, eg. > > $ btrfs -t bell be om -format=json subvolume list > > that would dump the list in json obviously, more formats could follow. >

Re: test if a subvolume is a snapshot?

o --tables or --structures .. just one switch). Instead reinventing the wheel just please try to look first how it is already done in completely predictable/guessable way: https://www.freebsd.org/cgi/man.cgi?query=zfs=8 https://www.freebsd.org/cgi/man.cgi?query=zpool=8 kloczek -- Tomasz Kłoczk

Re: test if a subvolume is a snapshot?

ng like this? Maybe someone already started doing this? kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH -- 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