On Wed, May 22, 2019 at 02:11:39PM -0500, Goldwyn Rodrigues wrote:
> On 10:46 21/05, Darrick J. Wong wrote:
> > On Mon, Apr 29, 2019 at 12:26:39PM -0500, Goldwyn Rodrigues wrote:
> > > From: Goldwyn Rodrigues
> > >
> > > Change dax_iomap_pfn to return the address as well in order to
> > > use it
On Wed, May 22, 2019 at 03:14:47PM -0500, Goldwyn Rodrigues wrote:
> On 9:51 21/05, Darrick J. Wong wrote:
> > On Mon, Apr 29, 2019 at 12:26:35PM -0500, Goldwyn Rodrigues wrote:
> > We cannot use @inline_data to convey the source address. @inline_data
> > (so far) is used to point to the in-memor
There are two regressions related to balance resume:
- Kernel NULL pointer dereference at mount time
Introduced in v5.0
- Kernel BUG_ON() just after mount
Introduced in v5.1
The kernel fixes are:
"btrfs: qgroup: Check if @bg is NULL to avoid NULL pointer
dereference"
"btrfs: reloc: Also queue
On 2019/5/22 下午10:37, Daniel Martinez wrote:
> Hello,
>
> I've converted an ext4 filesystem (after a few attempts, and after
> rolling back to a system running both the kernel and btrfs-progs 4.12)
> to a single disk btrfs filesystem, but to do so I needed to disable
> data checksums and small f
On 8:14 21/05, Darrick J. Wong wrote:
> On Mon, Apr 29, 2019 at 12:26:34PM -0500, Goldwyn Rodrigues wrote:
> > From: Goldwyn Rodrigues
> >
> > Perform a basic read using iomap support. The btrfs_iomap_begin()
> > finds the extent at the position and fills the iomap data
> > structure with the va
On 9:51 21/05, Darrick J. Wong wrote:
> On Mon, Apr 29, 2019 at 12:26:35PM -0500, Goldwyn Rodrigues wrote:
> > From: Goldwyn Rodrigues
> >
> > The IOMAP_DAX_COW is a iomap type which performs copy of
> > edges of data while performing a write if start/end are
> > not page aligned. The source add
From: Robbie Ko
[ Upstream commit 39ad317315887c2cb9a4347a93a8859326ddf136 ]
When doing fallocate, we first add the range to the reserve_list and
then reserve the quota. If quota reservation fails, we'll release all
reserved parts of reserve_list.
However, cur_offset is not updated to indicate
From: Josef Bacik
[ Upstream commit ff612ba7849964b1898fd3ccd1f56941129c6aab ]
We've been seeing the following sporadically throughout our fleet
panic: kernel BUG at fs/btrfs/relocation.c:4584!
netversion: 5.0-0
Backtrace:
#0 [c90003adb880] machine_kexec at 81041da8
#1 [c90003
From: Qu Wenruo
[ Upstream commit 10995c0491204c861948c9850939a7f4e90760a4 ]
Commit d2311e698578 ("btrfs: relocation: Delay reloc tree deletion after
merge_reloc_roots()") expands the life span of root->reloc_root.
This breaks certain checs of fs_info->reloc_ctl. Before that commit, if
we have
From: Robbie Ko
[ Upstream commit 39ad317315887c2cb9a4347a93a8859326ddf136 ]
When doing fallocate, we first add the range to the reserve_list and
then reserve the quota. If quota reservation fails, we'll release all
reserved parts of reserve_list.
However, cur_offset is not updated to indicate
From: Josef Bacik
[ Upstream commit ff612ba7849964b1898fd3ccd1f56941129c6aab ]
We've been seeing the following sporadically throughout our fleet
panic: kernel BUG at fs/btrfs/relocation.c:4584!
netversion: 5.0-0
Backtrace:
#0 [c90003adb880] machine_kexec at 81041da8
#1 [c90003
From: Qu Wenruo
[ Upstream commit 7ac1e464c4d473b517bb784f30d40da1f842482e ]
When we failed to find a root key in btrfs_update_root(), we just panic.
That's definitely not cool, fix it by outputting an unique error
message, aborting current transaction and return -EUCLEAN. This should
not norma
From: Robbie Ko
[ Upstream commit 39ad317315887c2cb9a4347a93a8859326ddf136 ]
When doing fallocate, we first add the range to the reserve_list and
then reserve the quota. If quota reservation fails, we'll release all
reserved parts of reserve_list.
However, cur_offset is not updated to indicate
From: Qu Wenruo
[ Upstream commit 7ac1e464c4d473b517bb784f30d40da1f842482e ]
When we failed to find a root key in btrfs_update_root(), we just panic.
That's definitely not cool, fix it by outputting an unique error
message, aborting current transaction and return -EUCLEAN. This should
not norma
From: Josef Bacik
[ Upstream commit ff612ba7849964b1898fd3ccd1f56941129c6aab ]
We've been seeing the following sporadically throughout our fleet
panic: kernel BUG at fs/btrfs/relocation.c:4584!
netversion: 5.0-0
Backtrace:
#0 [c90003adb880] machine_kexec at 81041da8
#1 [c90003
From: Josef Bacik
[ Upstream commit ff612ba7849964b1898fd3ccd1f56941129c6aab ]
We've been seeing the following sporadically throughout our fleet
panic: kernel BUG at fs/btrfs/relocation.c:4584!
netversion: 5.0-0
Backtrace:
#0 [c90003adb880] machine_kexec at 81041da8
#1 [c90003
From: Qu Wenruo
[ Upstream commit 7ac1e464c4d473b517bb784f30d40da1f842482e ]
When we failed to find a root key in btrfs_update_root(), we just panic.
That's definitely not cool, fix it by outputting an unique error
message, aborting current transaction and return -EUCLEAN. This should
not norma
From: Robbie Ko
[ Upstream commit 39ad317315887c2cb9a4347a93a8859326ddf136 ]
When doing fallocate, we first add the range to the reserve_list and
then reserve the quota. If quota reservation fails, we'll release all
reserved parts of reserve_list.
However, cur_offset is not updated to indicate
From: Qu Wenruo
[ Upstream commit 7ac1e464c4d473b517bb784f30d40da1f842482e ]
When we failed to find a root key in btrfs_update_root(), we just panic.
That's definitely not cool, fix it by outputting an unique error
message, aborting current transaction and return -EUCLEAN. This should
not norma
On 10:46 21/05, Darrick J. Wong wrote:
> On Mon, Apr 29, 2019 at 12:26:39PM -0500, Goldwyn Rodrigues wrote:
> > From: Goldwyn Rodrigues
> >
> > Change dax_iomap_pfn to return the address as well in order to
> > use it for performing a memcpy in case the type is IOMAP_DAX_COW.
> > We don't handle
On Wed, May 22, 2019 at 09:46:42PM +0300, Cerem Cem ASLAN wrote:
> Could you confirm or disclaim the following explanation:
> https://unix.stackexchange.com/a/520063/65781
Well, the quoted comment at the top is accurate (although I haven't
looked for the IRC conversation in question).
Howev
Could you confirm or disclaim the following explanation:
https://unix.stackexchange.com/a/520063/65781
On Tue, May 21, 2019 at 2:18 AM Hugo Mills wrote:
>
> On Tue, May 21, 2019 at 01:34:42AM -0700, Erik Jensen wrote:
> > I have a 5-drive btrfs filesystem. (raid-5 data, dup metadata). I can
> > mount it fine on my x86_64 system, and running `btrfs check` there
> > reveals no errors. However, I am n
Hello,
I've converted an ext4 filesystem (after a few attempts, and after
rolling back to a system running both the kernel and btrfs-progs 4.12)
to a single disk btrfs filesystem, but to do so I needed to disable
data checksums and small file inlining, otherwise I would get ENOSPC.
Now that I've
On Wed, May 22, 2019 at 10:37 AM Qu Wenruo wrote:
>
>
>
> On 2019/5/22 下午5:32, Filipe Manana wrote:
> > On Wed, May 22, 2019 at 9:40 AM Qu Wenruo wrote:
> >>
> >> There are two regressions that when mounting a partially balance btrfs
> >> after v5.1 kernel:
> >> - Kernel NULL pointer dereference
On 2019/5/22 下午5:32, Filipe Manana wrote:
> On Wed, May 22, 2019 at 9:40 AM Qu Wenruo wrote:
>>
>> There are two regressions that when mounting a partially balance btrfs
>> after v5.1 kernel:
>> - Kernel NULL pointer dereference at mount time
>> - Kernel BUG_ON() just after mount
>>
>> The kerne
On Wed, May 22, 2019 at 9:40 AM Qu Wenruo wrote:
>
> There are two regressions that when mounting a partially balance btrfs
> after v5.1 kernel:
> - Kernel NULL pointer dereference at mount time
> - Kernel BUG_ON() just after mount
>
> The kernel fixes are:
> "btrfs: qgroup: Check if @bg is NULL t
On Wed, May 22, 2019 at 11:33:39AM +0300, Nikolay Borisov wrote:
> > + memset(csum, 0xff, btrfs_super_csum_size(sctx->fs_info->super_copy));
David can you fold this in?
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index 65bd4999c7ad..d97039338952 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs
There are two regressions that when mounting a partially balance btrfs
after v5.1 kernel:
- Kernel NULL pointer dereference at mount time
- Kernel BUG_ON() just after mount
The kernel fixes are:
"btrfs: qgroup: Check if @bg is NULL to avoid NULL pointer
dereference"
"btrfs: reloc: Also queue orph
On Wed, May 22, 2019 at 11:33:39AM +0300, Nikolay Borisov wrote:
>
> > @@ -1799,16 +1801,22 @@ static int scrub_checksum_data(struct scrub_block
> > *sblock)
> > if (!sblock->pagev[0]->have_csum)
> > return 0;
> >
> > + shash->tfm = fs_info->csum_shash;
> > + shash->flags =
On 22.05.19 г. 11:19 ч., Johannes Thumshirn wrote:
> Currently btrfs_csum_data() relied on the crc32c() wrapper around the crypto
> framework for calculating the CRCs.
>
> As we have our own crypto_shash structure in the fs_info now, we can
> directly call into the crypto framework without goin
[BUG]
When a fs has orphan reloc tree along with unfinished balance:
...
item 16 key (TREE_RELOC ROOT_ITEM FS_TREE) itemoff 12090 itemsize 439
generation 12 root_dirid 256 bytenr 300400640 level 1 refs 0 <<<
lastsnap 8 byte_limit 0 bytes_used 1359872 flags
BTRFS has the implicit assumption that a checksum in compressed_bio is 4
bytes. While this is true for CRC32C, it is not for any other checksum.
Change the data type to be a byte array and adjust loop index calculation
accordingly.
Signed-off-by: Johannes Thumshirn
---
Changes to v2:
- Remove st
btrfs_print_data_csum_error() still assumed checksums to be 32 bit in size.
Make it size agnostic.
Signed-off-by: Johannes Thumshirn
Reviewed-by: Nikolay Borisov
---
fs/btrfs/btrfs_inode.h | 6 +++---
fs/btrfs/compression.c | 2 +-
fs/btrfs/inode.c | 4 ++--
3 files changed, 6 insertions
Currently btrfs is only supporting CRC32C as checksumming algorithm. As
this is about to change provide a function to validate the checksum type in
the superblock against all possible algorithms.
This makes adding new algorithms easier as there are fewer places to adjust
when adding new algorithms
BTRFS has the implicit assumption that a checksum in btrfs_orderd_sums is 4
bytes. While this is true for CRC32C, it is not for any other checksum.
Change the data type to be a byte array and adjust loop index calculation
accordingly.
This includes moving the adjustment of 'index' by 'ins_size' i
Add a small helper for btrfs_print_data_csum_error() which formats the
checksum according to it's type for pretty printing.
Signed-off-by: Johannes Thumshirn
Reviewed-by: Nikolay Borisov
---
fs/btrfs/btrfs_inode.h | 28
1 file changed, 24 insertions(+), 4 deletions(
Now that we have factorerd out the superblock checksum type validation, we
can check for supported superblock checksum types before doing the actual
validation of the superblock read from disk.
This leads the path to further simplifications of btrfs_check_super_csum()
later on.
Signed-off-by: Joh
btrfsic_test_for_metadata() directly calls the crc32c() library function
for calculating the CRC32C checksum, but then uses btrfs_csum_final() to
invert the result.
To ease further refactoring and development around checksumming in BTRFS
convert to calling btrfs_csum_data(), which is a wrapper aro
The CRC checksum in the free space cache is not dependant on the super
block's csum_type field but always a CRC32C.
So use btrfs_crc32c() and btrfs_crc32c_final() instead of btrfs_csum_data()
and btrfs_csum_final() for computing these checksums.
Signed-off-by: Johannes Thumshirn
Reviewed-by: Nik
Now that we everything in place, we can add SHA-256 as another checksum
algorithm.
SHA-256 was taken as it was the cryptographically strongest algorithm that
can fit into the 32 Bytes we have left.
Signed-off-by: Johannes Thumshirn
---
changes to v2:
- Add pre dependency on sha256
Changes to v1
Now that we have already checked for a valid checksum type before calling
btrfs_check_super_csum(), it can be simplified even further.
While at it get rid of the implicit size assumption of the resulting
checksum as well.
This is a preparation for changing all checksum functionality to use the
cr
Commit 9678c54388b6 ("btrfs: Remove custom crc32c init code") removed the
btrfs_crc32c() function, because it was a duplicate of the crc32c() library
function we already have in the kernel.
Resurrect it as a shim wrapper over crc32c() to make following
transformations of the checksumming code in b
Add boilerplate code for directly including the crypto framework.
This helps us flipping the switch for new algorithms.
Signed-off-by: Johannes Thumshirn
Reviewed-by: Nikolay Borisov
---
- Remove stray newline (David)
- Directly pass in csum_type to btrfs_init_csum_hash() (David)
- Don't use s
Currently btrfs_csum_data() relied on the crc32c() wrapper around the crypto
framework for calculating the CRCs.
As we have our own crypto_shash structure in the fs_info now, we can
directly call into the crypto framework without going trough the wrapper.
This way we can even remove the btrfs_csu
This patchset add support for adding new checksum types in BTRFS.
Currently BTRFS only supports CRC32C as data and metadata checksum, which is
good if you only want to detect errors due to data corruption in hardware.
But CRC32C isn't able cover other use-cases like de-duplication or
cryptographi
On Tue, May 21, 2019 at 04:22:59PM +0200, David Sterba wrote:
> This reverts changed done in 9678c54388b6a6b309ff7ee5c8d23fa9eba7c06f,
> using LIBCRC32C adds the module dependency so this is automatically picked
> when building the initrd. CRYPTO_CRC32C needed workarounds to manually
> pick crc32c
47 matches
Mail list logo
