On 07/23/18 18:50, David Sterba wrote:
On Mon, Jul 23, 2018 at 04:13:26PM +0200, Holger Hoffstätte wrote:
While backporting a bunch of fixes to my own 4.16.x tree
(4.17 had a few too many bugs for my taste) I also ended up merging:
Curious, bugs in btrfs or the whole 4.17 kernel? And if bugs,
On Mon, Jul 23, 2018 at 04:13:26PM +0200, Holger Hoffstätte wrote:
> While backporting a bunch of fixes to my own 4.16.x tree
> (4.17 had a few too many bugs for my taste) I also ended up merging:
Curious, bugs in btrfs or the whole 4.17 kernel? And if bugs, real
breakage or backported fixes?
--
T
On 07/23/2018 04:25 PM, Holger Hoffstätte wrote:
>
> I wanted to migrate my collection of questionable shell scripts for btrfs
> maintenance/inspection to a more stable foundation and therefore created
> Gentoo ebuilds for Hans van Kranenburg's excellent python-btrfs [1] and
> btrfs-heatmap [2] pa
On Wed, Jul 18, 2018 at 12:08:59AM +0200, Adam Borowski wrote:
> Requiring a rw descriptor conflicts both ways with exec, returning ETXTBSY
> whenever you try to defrag a program that's currently being run, or
> causing intermittent exec failures on a live system being defragged.
>
> As defrag doe
On 07/23/18 16:39, Patrik Lundquist wrote:
$ uname -a
Linux nas 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64 GNU/Linux
$ dmesg | grep Btrfs
[8.168408] Btrfs loaded, crc32c=crc32c-intel
$ lsmod | grep crc32
crc32_pclmul 16384 0
libcrc32c 16384 1 btrfs
cr
$ uname -a
Linux nas 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64 GNU/Linux
$ dmesg | grep Btrfs
[8.168408] Btrfs loaded, crc32c=crc32c-intel
$ lsmod | grep crc32
crc32_pclmul 16384 0
libcrc32c 16384 1 btrfs
crc32c_generic 16384 0
crc32c_intel
subscribe linux-btrfs
I wanted to migrate my collection of questionable shell scripts for btrfs
maintenance/inspection to a more stable foundation and therefore created
Gentoo ebuilds for Hans van Kranenburg's excellent python-btrfs [1] and
btrfs-heatmap [2] packages.
They can be found in my overlay at:
https://git
On 07/23/2018 09:57 PM, David Sterba wrote:
On Fri, Jul 20, 2018 at 07:18:54PM +0800, Anand Jain wrote:
On 07/19/2018 07:53 PM, David Sterba wrote:
On Mon, Jul 16, 2018 at 10:58:11PM +0800, Anand Jain wrote:
When the replace is running the fs_devices::num_devices also includes
the replace
Hi,
While backporting a bunch of fixes to my own 4.16.x tree
(4.17 had a few too many bugs for my taste) I also ended up merging:
df91f56adce1f: libcrc32c: Add crc32c_impl function
9678c54388b6a: btrfs: Remove custom crc32c init code
..which AFAIK went into 4.17 and seemed harmless enough; afte
On 07/23/2018 10:01 PM, David Sterba wrote:
On Mon, Jul 16, 2018 at 10:58:10PM +0800, Anand Jain wrote:
In preparation to de-duplicate a section of code where we deduce the
num_devices, use warn instead of bug.
Signed-off-by: Anand Jain
---
fs/btrfs/volumes.c | 2 +-
1 file changed, 1 in
On Mon, Jul 16, 2018 at 10:58:10PM +0800, Anand Jain wrote:
> In preparation to de-duplicate a section of code where we deduce the
> num_devices, use warn instead of bug.
>
> Signed-off-by: Anand Jain
> ---
> fs/btrfs/volumes.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --
On Fri, Jul 20, 2018 at 07:18:54PM +0800, Anand Jain wrote:
>
>
> On 07/19/2018 07:53 PM, David Sterba wrote:
> > On Mon, Jul 16, 2018 at 10:58:11PM +0800, Anand Jain wrote:
> >> When the replace is running the fs_devices::num_devices also includes
> >> the replace device, however in some operati
On Fri, Jul 20, 2018 at 07:37:46PM +0300, Nikolay Borisov wrote:
> Here are a bunch of patches which cleanup extraneous fs_info parameters to
> function which already take a structure that holds a reference to the
> fs_info.
>
> Except for patches 4 and 5, everything else is correct - due to th
On Fri, Jul 20, 2018 at 11:46:10AM -0700, Omar Sandoval wrote:
> From: Josef Bacik
>
> We recently ran into the following deadlock involving
> btrfs_write_inode():
>
> [ +0.005066] __schedule+0x38e/0x8c0
> [ +0.007144] schedule+0x36/0x80
> [ +0.006447] bit_wait+0x11/0x60
> [ +0.006446] _
Print csum for a given file on stdout.
Sample usage:
btrfs inspect-internal dump-csum /btrfs/50gbfile /dev/sda4
Signed-off-by: Lakshmipathi.G
---
Makefile | 2 +-
cmds-inspect-dump-csum.c | 239 +++
cmds-inspect-dump-csum.h | 22
On Mon, Jul 23, 2018 at 02:47:29PM +0800, Qu Wenruo wrote:
> In find_free_extent() under checks: tag, we have the following code
>
> --
> search_start = ALIGN(offset, fs_info->stripesize);
> /* move on to the next group */
> if (search_start + num_byte
On Mon, Jul 23, 2018 at 09:10:09AM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> At send.c:full_send_tree() we were setting the 'key' variable in the loop
> while never using it later. We were also using two btrfs_key variables
> to store the initial key for search and the key found
From: Filipe Manana
Test that we are able to do send operations when one of the source
snapshots (or subvolume) has a file that is deleted while there is still
a open file descriptor for that file.
This test is motivated by a bug found in btrfs which is fixed by a patch
for the linux kernel titl
From: Filipe Manana
At send.c:full_send_tree() we were setting the 'key' variable in the loop
while never using it later. We were also using two btrfs_key variables
to store the initial key for search and the key found in every iteration
of the loop. So remove this useless key assignment and use
From: Filipe Manana
The more common use case of send involves creating a RO snapshot and then
use it for a send operation. In this case it's not possible to have inodes
in the snapshot that have a link count of zero (inode with an orphan item)
since during snapshot creation we do the orphan clean
On 07/21/2018 02:01 PM, Lu Fengqi wrote:
On Tue, Jul 03, 2018 at 05:07:24PM +0800, Anand Jain wrote:
When a device is deleted, the btrfs_super_block::number_devices is
reduced by 1, but we do that after the commit transaction, so this
change did not made it to the disk and waits for the next
22 matches
Mail list logo
