On 20.03.2018 21:25, je...@suse.com wrote:
> From: Jeff Mahoney
>
> Any time the first block group of a new type is created, we add a new
> kobject to sysfs to hold the attributes for that type. Kobject-internal
> allocations always use GFP_KERNEL, making them prone to fs-reclaim races.
> Whil
On 20.03.2018 21:25, je...@suse.com wrote:
> From: Jeff Mahoney
>
> Since commit 2be12ef79 (btrfs: Separate space_info create/update), we've
> separated out the creation and updating of the space info structures.
> That commit was a straightforward refactoring of the two parts of
> update_space
On 21.03.2018 01:33, Anand Jain wrote:
> Return the required -EINVAL and -EUCLEAN from the function
> btrfs_check_super_csum(). And more the error log into the
> parent function.
>
> Signed-off-by: Anand Jain
> ---
> fs/btrfs/disk-io.c | 28 +---
> 1 file changed, 17 in
On 21.03.2018 01:33, Anand Jain wrote:
> %csum_type is being checked to check the number of csum types we support,
> which is 1 as of now. Instead just check if the type matches with the
> only type we support, that is BTRFS_CSUM_TYPE_CRC32. And further adds
> cleanup.
>
> Signed-off-by: Anand J
On 03/21/2018 10:37 AM, Anand Jain wrote:
@@ -418,8 +418,10 @@ static int btrfs_check_super_csum(struct
btrfs_fs_info *fs_info,
crc, BTRFS_SUPER_INFO_SIZE - BTRFS_CSUM_SIZE);
btrfs_csum_final(crc, result);
- if (memcmp(raw_disk_sb, result, sizeof(result)))
-
@@ -418,8 +418,10 @@ static int btrfs_check_super_csum(struct btrfs_fs_info
*fs_info,
crc, BTRFS_SUPER_INFO_SIZE - BTRFS_CSUM_SIZE);
btrfs_csum_final(crc, result);
- if (memcmp(raw_disk_sb, result, sizeof(result)))
- return 1;
+ if
On 2018年03月21日 01:44, Mike Stevens wrote:
>
>>> 30 devices is really not that much, heck you get 90 disks top load JBOD
>>> storage chassis these days and BTRFS does sound like an attractive choice
>>> for things like that.
>
>> So Mike's case is, that both metadata and data are configured as
>
On Tue, Mar 20, 2018 at 04:26:52PM -0700, Linus Torvalds wrote:
> On Tue, Mar 20, 2018 at 4:23 PM, Linus Torvalds
> wrote:
> >
> > Hmm. So thanks to the diseased mind of Martin Uecker, there's a better
> > test for "__is_constant()":
> >
> > /* Glory to Martin Uecker */
> > #define __is_const
Return the required -EINVAL and -EUCLEAN from the function
btrfs_check_super_csum(). And more the error log into the
parent function.
Signed-off-by: Anand Jain
---
fs/btrfs/disk-io.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/fs/btrfs/disk-
%csum_type is being checked to check the number of csum types we support,
which is 1 as of now. Instead just check if the type matches with the
only type we support, that is BTRFS_CSUM_TYPE_CRC32. And further adds
cleanup.
Signed-off-by: Anand Jain
---
fs/btrfs/disk-io.c | 41 +++
v1->v2:
Merge 2/3 and 3/3
Use -EUCLEAN for csum mismatch
Move the error logging to the parent function
Drop the struct btrfs_fsinfo as the argument for
btrfs_check_super_csum()
Do not make btrfs_check_super_csum() nonstatic here, it will be part
of the patchset which will
On Tue, Mar 20, 2018 at 4:23 PM, Linus Torvalds
wrote:
>
> Hmm. So thanks to the diseased mind of Martin Uecker, there's a better
> test for "__is_constant()":
>
> /* Glory to Martin Uecker */
> #define __is_constant(a) \
> (sizeof(int) == sizeof(*(1 ? ((void*)((a) * 0l)) : (int*)1)))
On Sat, Mar 17, 2018 at 1:07 PM, Kees Cook wrote:
>
> No luck! :( gcc 4.4 refuses to play along. And, hilariously, not only
> does it not change the complaint about __builtin_choose_expr(), it
> also thinks that's a VLA now.
Hmm. So thanks to the diseased mind of Martin Uecker, there's a better
t
On 03/20/2018 07:10 PM, Nikolay Borisov wrote:
On 20.03.2018 11:53, Anand Jain wrote:
In preparation to use the function btrfs_check_super_csum() for
the device scan context, make it nonstatic and pass the
struct block_device instead of the struct fs_info.
Signed-off-by: Anand Jain
---
f
@@ -418,8 +418,10 @@ static int btrfs_check_super_csum(struct btrfs_fs_info
*fs_info,
crc, BTRFS_SUPER_INFO_SIZE - BTRFS_CSUM_SIZE);
btrfs_csum_final(crc, result);
- if (memcmp(raw_disk_sb, result, sizeof(result)))
- return 1;
+ if
On 03/19/2018 08:34 AM, Nikolay Borisov wrote:
> You are hitting a warning that was removed in : c8195a7b1ad5 ("btrfs:
> remove spurious WARN_ON(ref->count < 0) in find_parent_nodes")
>
>
> In short - you can disregard it. However, it's likely you will continue
> seeing it in the future unless y
On 03/20/2018 07:45 AM, Misono, Tomohiro wrote:
> Deletion of subvolume by non-privileged user is completely restricted
> by default because we can delete a subvolume even if it is not empty
> and may cause data loss. In other words, when user_subvol_rm_allowed
> mount option is used, a user can de
On 03/19/2018 07:06 PM, Liu Bo wrote:
[...]
>
> So Mike's case is, that both metadata and data are configured as
> raid6, and the operations, balance and scrub, that he tried, need to
> set the existing block group as readonly (in order to avoid any
> further changes being applied during operation
From: Jeff Mahoney
Any time the first block group of a new type is created, we add a new
kobject to sysfs to hold the attributes for that type. Kobject-internal
allocations always use GFP_KERNEL, making them prone to fs-reclaim races.
While it appears as if this can occur any time a block group
From: Jeff Mahoney
Since commit 2be12ef79 (btrfs: Separate space_info create/update), we've
separated out the creation and updating of the space info structures.
That commit was a straightforward refactoring of the two parts of
update_space_info, but we can go a step further. Since commits
c5902
>> 30 devices is really not that much, heck you get 90 disks top load JBOD
>> storage chassis these days and BTRFS does sound like an attractive choice
>> for things like that.
> So Mike's case is, that both metadata and data are configured as
> raid6, and the operations, balance and scrub, that
On 2018年03月20日 16:45, Nikolay Borisov wrote:
> Currently we print the raw values of the owner field of leaf/nodes.
> This can result in output like the following:
>
> leaf 30490624 items 2 free space 16061 generation 4 owner 18446744073709551607
>
> With the patch applied the same leaf looks li
On 20.03.2018 11:53, Anand Jain wrote:
> In preparation to use the function btrfs_check_super_csum() for
> the device scan context, make it nonstatic and pass the
> struct block_device instead of the struct fs_info.
>
> Signed-off-by: Anand Jain
> ---
> fs/btrfs/disk-io.c | 12 ++--
>
/Qu-Wenruo/btrfs-Validate-child-tree-block-s-level-and-first-key/20180320-054353
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> fs/btrfs/ref-verify.c:586:45: sparse
On 20.03.2018 12:11, Nikolay Borisov wrote:
>
>
> On 20.03.2018 11:53, Anand Jain wrote:
>> %csum_type is being checked to check the number of csum types we support,
>> which is 1 as of now. Instead just check if the type matches with the
>> only type we support, that is BTRFS_CSUM_TYPE_CRC32.
On 20.03.2018 11:53, Anand Jain wrote:
> Return the required -EINVAL from the function btrfs_check_super_csum()
> and move the error logging into the btrfs_check_super_csum() itself.
>
> Signed-off-by: Anand Jain
> ---
> fs/btrfs/disk-io.c | 13 +++--
> 1 file changed, 7 insertions(+),
On 20.03.2018 11:53, Anand Jain wrote:
> %csum_type is being checked to check the number of csum types we support,
> which is 1 as of now. Instead just check if the type matches with the
> only type we support, that is BTRFS_CSUM_TYPE_CRC32. And further adds
> cleanup.
>
> Signed-off-by: Anand J
%csum_type is being checked to check the number of csum types we support,
which is 1 as of now. Instead just check if the type matches with the
only type we support, that is BTRFS_CSUM_TYPE_CRC32. And further adds
cleanup.
Signed-off-by: Anand Jain
---
fs/btrfs/disk-io.c | 41 +++
Anand Jain (3):
btrfs: cleanup btrfs_check_super_csum() to check the csum_type to the
type
btrfs: return required error from btrfs_check_super_csum
btrfs: refactor btrfs_check_super_csum() for scan
fs/btrfs/disk-io.c | 50 --
fs/btrfs/disk
In preparation to use the function btrfs_check_super_csum() for
the device scan context, make it nonstatic and pass the
struct block_device instead of the struct fs_info.
Signed-off-by: Anand Jain
---
fs/btrfs/disk-io.c | 12 ++--
fs/btrfs/disk-io.h | 1 +
2 files changed, 7 insertions(
Return the required -EINVAL from the function btrfs_check_super_csum()
and move the error logging into the btrfs_check_super_csum() itself.
Signed-off-by: Anand Jain
---
fs/btrfs/disk-io.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/b
On 03/20/2018 03:32 AM, David Sterba wrote:
On Sat, Mar 17, 2018 at 06:27:15PM +0100, Christoph Biedl wrote:
Greg Kroah-Hartman wrote...
On Thu, Mar 15, 2018 at 07:55:42PM +0100, Christoph Biedl wrote:
commit 3c181c12c431fe33b669410d663beb9cceefcd1b upstream.
On big-endian systems, thi
On 2018年03月20日 14:47, Misono, Tomohiro wrote:
>
> Signed-off-by: Tomohiro Misono
Reviewed-by: Qu Wenruo
BTW this reminds me that, btrfs-progs is still using BTRFS_CRC32_SIZE
macro which the original comment is for.
It may be a good time to clean it up in btrfs-progs.
Thanks,
Qu
> ---
> f
Currently we print the raw values of the owner field of leaf/nodes.
This can result in output like the following:
leaf 30490624 items 2 free space 16061 generation 4 owner 18446744073709551607
With the patch applied the same leaf looks like:
leaf 30490624 items 2 free space 16061 generation 4 ow
34 matches
Mail list logo
