[PATCH] btrfs: change btrfs_csum_final result param type to u8

--- fs/btrfs/disk-io.c | 2 +- fs/btrfs/disk-io.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index 50bed6c..95bd34f 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -273,7 +273,7 @@ u32 btrfs_csum_data(char *data, u32

[PATCH] btrfs: change btrfs_csum_final result param type to u8

csum member of struct btrfs_super_block has array type of u8. It makes sense that function btrfs_csum_final should be also declared to accept u8 *. I changed the declaration of method void btrfs_csum_final(u32 crc, char *result); to void btrfs_csum_final(u32 crc, u8 *result); Domagoj Tršan (1):

[PATCH] btrfs-progs: change btrfs_csum_final result param type to u8

Signed-off-by: Domagoj Tršan --- btrfs-image.c | 2 +- chunk-recover.c | 2 +- cmds-check.c | 2 +- cmds-inspect-dump-super.c | 2 +- disk-io.c | 10 +- disk-io.h | 2 +- file-item.c

[PATCH] btrfs-progs: change btrfs_csum_final result param type to u8

csum member of struct btrfs_super_block has array type of u8. It makes sense that function btrfs_csum_final should be also declared to accept u8 *. I changed the declaration of method void btrfs_csum_final(u32 crc, char *result); to void btrfs_csum_final(u32 crc, u8 *result); Also, I changed

Re: [RFC] Preliminary BTRFS Encryption

On Fri, Sep 16, 2016 at 07:56:02PM +0800, Anand Jain wrote: > > > >> however here below is the quick example > >> on the cli usage. Please try out, let me know if I have missed something. > >> > >> Also would like to mention that a review from the security experts is due, > >> which is important

Re: [RFC] Preliminary BTRFS Encryption

On Sat, Sep 17, 2016 at 10:12 AM, Anand Jain wrote: > btrfs keeps it only in-memory and key hash goes to the disk. > Further in the long we need an integration with key management > system as well. Maybe LUKS2 is usable for this part, and still adaptable since it's

Re: [RFC] Preliminary BTRFS Encryption

On Sat, Sep 17, 2016 at 12:38:30AM -0400, Zygo Blaxell wrote: > There's also a nasty problem with the extent tree--there's only one per > filesystem, it's shared between all subvols and block groups, and every > extent in that tree has back references to the (possibly encrypted) subvol > trees.

Re: [RFC] Preliminary BTRFS Encryption

Hi Eric, Thanks for the constructive feedback, pls see inline below. On 09/17/2016 02:58 PM, Eric Biggers wrote: On Tue, Sep 13, 2016 at 09:39:46PM +0800, Anand Jain wrote: This patchset adds btrfs encryption support. Hi Anand, I'm part of a team that will be maintaining and

Re: Size of scrubbed Data

On Sat, Sep 17, 2016 at 8:34 AM, Tim Walberg wrote: > On 09/15/2016 15:18 -0600, Chris Murphy wrote: >>> > System, single: total=4.00MiB, used=0.00B >>> > Metadata, RAID1: total=10.00GiB, used=8.14GiB >>> > GlobalReserve, single: total=512.00MiB, used=0.00B

Re: Size of scrubbed Data

On 09/17/2016 09:34 -0500, Walberg, Tim wrote: >> On 09/15/2016 15:18 -0600, Chris Murphy wrote: >> >> > System, single: total=4.00MiB, used=0.00B >> >> > Metadata, RAID1: total=10.00GiB, used=8.14GiB >> >> > GlobalReserve, single: total=512.00MiB, used=0.00B >>

Re: Size of scrubbed Data

On 09/15/2016 15:18 -0600, Chris Murphy wrote: >> > System, single: total=4.00MiB, used=0.00B >> > Metadata, RAID1: total=10.00GiB, used=8.14GiB >> > GlobalReserve, single: total=512.00MiB, used=0.00B >> >> btrfs balance start -mconvert=raid1,soft Since the single

Re: Size of scrubbed Data

On Sat, Sep 17, 2016 at 01:02:18PM +0200, Stefan Malte Schumacher wrote: > Concerning Testing: I only use it on desktops and home servers, which > do not offer any services to the net. I am very fond of Debian and > always use stable or even old-stable on work servers, but was finally > to annoyed

Re: Size of scrubbed Data

Hello Thanks for the information. I did another run of scrubbing et voila: total bytes scrubbed: 12.11TiB with 0 errors, which is pretty much two times the amount of actual data stored on the filesystem. I am relieved, but still would like to know why this went wrong in the first place and why it

Re: compress=lzo safe to use?

Am Mon, 12 Sep 2016 04:36:07 + (UTC) schrieb Duncan <1i5t5.dun...@cox.net>: > Again, I once thought all this was just the stage at which btrfs was, > until I found out that it doesn't seem to happen if btrfs compression > isn't being used. Something about the way it recovers from checksum

Re: [RFC] Preliminary BTRFS Encryption

On Fri, 16 Sep 2016 23:58:31 -0700, Eric Biggers wrote: > On Tue, Sep 13, 2016 at 09:39:46PM +0800, Anand Jain wrote: >> >> This patchset adds btrfs encryption support. >> >> > Hi Anand, > Note: even better would be an authenticated encryption mode. That isn't > yet done by ext4 or f2fs --- I

Re: [RFC] Preliminary BTRFS Encryption

On Tue, Sep 13, 2016 at 09:39:46PM +0800, Anand Jain wrote: > > This patchset adds btrfs encryption support. > Hi Anand, I'm part of a team that will be maintaining and improving ext4 encryption. Because f2fs now shares much of the code, it will benefit from the ext4 encryption work too. It

Re: [RFC] Preliminary BTRFS Encryption

On Sat, 17 Sep 2016 00:38:30 -0400, Zygo Blaxell wrote: > On Fri, Sep 16, 2016 at 06:49:53AM +, Alex Elsayed wrote: >> The main issue I see is that subvolumes as btrfs has them _do_ >> introduce novel concerns - in particular, how should snapshots interact >> with keying (and nonces)? None of