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?
--
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]
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
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
$ 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:
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
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;
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
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
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
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 +
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
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
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
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
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_bytes >
block_group->key.objectid +
On 2018年07月23日 14:22, 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_bytes >
>
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_bytes >
block_group->key.objectid +
25 matches
Mail list logo
