Re: attacking btrfs filesystems via UUID collisions?

On 2015-12-15 09:42, Hugo Mills wrote: On Tue, Dec 15, 2015 at 09:27:12AM -0500, Austin S. Hemmelgarn wrote: On 2015-12-15 09:18, Hugo Mills wrote: On Tue, Dec 15, 2015 at 08:54:01AM -0500, Austin S. Hemmelgarn wrote: On 2015-12-14 16:26, Chris Murphy wrote: On Mon, Dec 14, 2015 at 6:23 AM,

Btrfs: check for empty bitmap list in setup_cluster_bitmaps

Dave Jones found a warning from kasan in setup_cluster_bitmaps() == BUG: KASAN: stack-out-of-bounds in setup_cluster_bitmap+0xc4/0x5a0 at addr 88039bef6828 Read of size 8 by task nfsd/1009 page:ea000e6fbd80 count:0 mapcount:0

Re: !PageLocked BUG_ON hit in clear_page_dirty_for_io

On Tue, Dec 15, 2015 at 12:03 AM, Chris Mason wrote: > On Tue, Dec 08, 2015 at 11:25:28PM -0500, Dave Jones wrote: >> Not sure if I've already reported this one, but I've been seeing this >> a lot this last couple days. >> >> kernel BUG at mm/page-writeback.c:2654! >> invalid opcode:

Re: Btrfs: check for empty bitmap list in setup_cluster_bitmaps

On 12/15/2015 12:08 PM, Chris Mason wrote: Dave Jones found a warning from kasan in setup_cluster_bitmaps() == BUG: KASAN: stack-out-of-bounds in setup_cluster_bitmap+0xc4/0x5a0 at addr 88039bef6828 Read of size 8 by task

Re: Btrfs: check for empty bitmap list in setup_cluster_bitmaps

On Tue, Dec 15, 2015 at 01:37:01PM -0500, Josef Bacik wrote: > On 12/15/2015 12:08 PM, Chris Mason wrote: > >Dave Jones found a warning from kasan in setup_cluster_bitmaps() > > > >== > >BUG: KASAN: stack-out-of-bounds in

[PATCH] Btrfs-progs: ftw_add_entry_size: Round up file size to sectorsize

ftw_add_entry_size() assumes 4k as the block size of the underlying filesystem and hence the file sizes computed is incorrect for non-4k sectorsized filesystems. Fix this by rounding up file sizes to sectorsize. Signed-off-by: Chandan Rajendra --- mkfs.c | 8

Re: Will "btrfs check --repair" fix the mounting problem?

2015-12-15 1:42 GMT+00:00 Qu Wenruo : > You'll see output like the following: > Well block 29491200(gen: 5 level: 0) seems good, and it matches superblock > Well block 29376512(gen: 4 level: 0) seems good, but generation/level > doesn't match, want gen: 5 level: 0 > > The

Re: [PATCH 0/3] btrfs-progs: fix file restore to lost+found bug

On Tue, Dec 08, 2015 at 11:06:28AM +0900, Naohiro Aota wrote: > On Tue, Dec 8, 2015 at 12:35 AM, David Sterba wrote: > > On Mon, Dec 07, 2015 at 11:59:19AM +0900, Naohiro Aota wrote: > >> > But I only see the first 2 patches in maillist... > >> > The last test case seems missing?

[PATCH 0/4] btrfs: return all mirror whether need_raid_map set or not

__btrfs_map_block() should return all mirror on WRITE, REQ_GET_READ_MIRRORS, and RECOVERY case, whether need_raid_map set or not. need_raid_map only used to control is to set bbio->raid_map. Current code works right becuase there is only one caller can trigger above bug, which is readahead, and

[PATCH 3/4] btrfs: Small cleanup for get index_srcdev loop

1: Adjust condition in loop to make less TAB 2: Move btrfs_put_bbio()'s line for combine, and makes logic clean. Signed-off-by: Zhao Lei --- fs/btrfs/volumes.c | 42 -- 1 file changed, 20 insertions(+), 22 deletions(-) diff --git

[PATCH 1/4] btrfs: Disable raid56 readahead

Raid56 readahead can not work in current code, reada_find_extent() will show warning of bbio->num_stripes > BTRFS_MAX_MIRRORS, because raid56 have parity strip, which makes more bbio->num_stripes. The reason why we haven't see above error is because another bug in __btrfs_map_block(), which make

[PATCH 4/4] btrfs: Use direct way to determine raid56 write/recover mode

Old code use bbio->raid_map to determine whether in raid56 write/recover operation, because we don't have bbio->map_type that time, and have to use above workaround. Now we have direct way for this condition, to get gid of using the function-relative data, and make code readable. Signed-off-by:

[PATCH 2/4] btrfs: return all mirror whether need_raid_map set or not

__btrfs_map_block() should return all mirror on WRITE, REQ_GET_READ_MIRRORS, and RECOVERY case, whether need_raid_map set or not. need_raid_map only used to control is to set bbio->raid_map. Current code works right because there is only one caller can trigger above bug, which is readahead, and

Re: Still not production ready

Am Dienstag, 15. Dezember 2015, 16:59:58 CET schrieb Chris Mason: > On Mon, Dec 14, 2015 at 10:08:16AM +0800, Qu Wenruo wrote: > > Martin Steigerwald wrote on 2015/12/13 23:35 +0100: > > >Hi! > > > > > >For me it is still not production ready. > > > > Yes, this is the *FACT* and not everyone has

Re: Will "btrfs check --repair" fix the mounting problem?

Ivan Sizov wrote on 2015/12/15 09:34 +: 2015-12-15 1:42 GMT+00:00 Qu Wenruo : You'll see output like the following: Well block 29491200(gen: 5 level: 0) seems good, and it matches superblock Well block 29376512(gen: 4 level: 0) seems good, but generation/level

Re: [4.3-rc4] scrubbing aborts before finishing (probably solved)

Am Montag, 14. Dezember 2015, 08:59:59 CET schrieb Martin Steigerwald: > Am Mittwoch, 25. November 2015, 16:35:39 CET schrieben Sie: > > Am Samstag, 31. Oktober 2015, 12:10:37 CET schrieb Martin Steigerwald: > > > Am Donnerstag, 22. Oktober 2015, 10:41:15 CET schrieb Martin Steigerwald: > > > > I

ERROR: did not find source subvol

kernel 4.2.6-301.fc23.x86_64 btrfs-progs-4.2.2-1.fc23.x86_64 This is a new one for me. Two new Btrfs volumes (one single profile, one 2x raid1) both created with this btrfs-progs. And then [root@f23a chrisbackup]# btrfs send everything-20150922/ | btrfs receive /mnt/br1-500g/ At subvol

Re: dear developers, can we have notdatacow + checksumming, plz?

On 2015-12-14 22:15, Christoph Anton Mitterer wrote: On Mon, 2015-12-14 at 09:16 -0500, Austin S. Hemmelgarn wrote: When one starts to get a bit deeper into btrfs (from the admin/end- user side) one sooner or later stumbles across the recommendation/need to use nodatacow for certain types of

Re: Still not production ready

On Wed, Dec 16, 2015 at 10:19:00AM +0800, Qu Wenruo wrote: > > > Liu Bo wrote on 2015/12/15 17:53 -0800: > >On Wed, Dec 16, 2015 at 09:20:45AM +0800, Qu Wenruo wrote: > >> > >> > >>Chris Mason wrote on 2015/12/15 16:59 -0500: > >>>On Mon, Dec 14, 2015 at 10:08:16AM +0800, Qu Wenruo wrote: >

Re: attacking btrfs filesystems via UUID collisions?

On 2015-12-14 16:26, Chris Murphy wrote: On Mon, Dec 14, 2015 at 6:23 AM, Austin S. Hemmelgarn wrote: Agreed, if yo9u can't substantiate _why_ it's bad practice, then you aren't making a valid argument. The fact that there is software that doesn't handle it well would

Re: [PATCH v3] btrfs: Introduce new mount option to disable tree log replay

On 2015-12-14 18:34, Christoph Anton Mitterer wrote: On Mon, 2015-12-14 at 15:20 -0500, Austin S. Hemmelgarn wrote: On 2015-12-14 14:44, Christoph Anton Mitterer wrote: On Mon, 2015-12-14 at 14:33 -0500, Austin S. Hemmelgarn wrote: The traditional reasoning was that read-only meant that users

Re: Still not production ready

On Mon, Dec 14, 2015 at 10:08:16AM +0800, Qu Wenruo wrote: > > > Martin Steigerwald wrote on 2015/12/13 23:35 +0100: > >Hi! > > > >For me it is still not production ready. > > Yes, this is the *FACT* and not everyone has a good reason to deny it. > > >Again I ran into: > > > >btrfs kworker

Re: Btrfs: check for empty bitmap list in setup_cluster_bitmaps

Hi Chris, I have one coding comment for this patch. Following line can be merged into single: if (!list_empty(bitmaps)) entry = list_first_entry(bitmaps, struct btrfs_free_space, list); new change as below-: entry = list_first_entry_or_null(bitmaps, struct btrfs_free_space,list);

need to recover large file

Hi: I just screwed up… spent the last 3 weeks generting a 400G file (genome assembly) . Went to back it up and swapped the arguments to tar (tar Jcf my_precious my_precious.tar.xz) what was once 400G is now 108 bytes of xz header - argh. This is on a 6-volume btrfs filesystem. I

Re: Still not production ready

Chris Mason wrote on 2015/12/15 16:59 -0500: On Mon, Dec 14, 2015 at 10:08:16AM +0800, Qu Wenruo wrote: Martin Steigerwald wrote on 2015/12/13 23:35 +0100: Hi! For me it is still not production ready. Yes, this is the *FACT* and not everyone has a good reason to deny it. Again I ran

Re: [PATCH v3] btrfs: Introduce new mount option to disable tree log replay

David Sterba wrote on 2015/12/14 18:32 +0100: On Thu, Dec 10, 2015 at 10:34:06AM +0800, Qu Wenruo wrote: Introduce a new mount option "nologreplay" to co-operate with "ro" mount option to get real readonly mount, like "norecovery" in ext* and xfs. Since the new parse_options() need to check

Re: Still not production ready

Liu Bo wrote on 2015/12/15 17:53 -0800: On Wed, Dec 16, 2015 at 09:20:45AM +0800, Qu Wenruo wrote: Chris Mason wrote on 2015/12/15 16:59 -0500: On Mon, Dec 14, 2015 at 10:08:16AM +0800, Qu Wenruo wrote: Martin Steigerwald wrote on 2015/12/13 23:35 +0100: Hi! For me it is still not

[PATCH] Btrfs: fix output of compression message in btrfs_parse_options()

The compression message might not be correctly output. Fix it. [[before fix]] # mount -o compress /dev/sdb3 /test3 [ 996.874264] BTRFS info (device sdb3): disk space caching is enabled [ 996.874268] BTRFS: has skinny extents # mount | grep /test3 /dev/sdb3 on /test3 type btrfs

Re: need to recover large file

... Didn't read all of your original post originally, because I haven't been into those internals. Now that I have, I see it seems to be using 6 devices, so you might have to use 1 hard drive 6*size of partition (others can say if this will work), or 6 other hard drives to make the backups.

Re: attacking btrfs filesystems via UUID collisions?

On Tue, Dec 15, 2015 at 08:54:01AM -0500, Austin S. Hemmelgarn wrote: > On 2015-12-14 16:26, Chris Murphy wrote: > >On Mon, Dec 14, 2015 at 6:23 AM, Austin S. Hemmelgarn > > wrote: > >> > >>Agreed, if yo9u can't substantiate _why_ it's bad practice, then you aren't > >>making

Re: attacking btrfs filesystems via UUID collisions?

On Tue, Dec 15, 2015 at 09:27:12AM -0500, Austin S. Hemmelgarn wrote: > On 2015-12-15 09:18, Hugo Mills wrote: > >On Tue, Dec 15, 2015 at 08:54:01AM -0500, Austin S. Hemmelgarn wrote: > >>On 2015-12-14 16:26, Chris Murphy wrote: > >>>On Mon, Dec 14, 2015 at 6:23 AM, Austin S. Hemmelgarn >

Re: attacking btrfs filesystems via UUID collisions?

On 2015-12-14 19:08, Christoph Anton Mitterer wrote: On Mon, 2015-12-14 at 08:23 -0500, Austin S. Hemmelgarn wrote: The reason that this isn't quite as high of a concern is because performing this attack requires either root access, or direct physical access to the hardware, and in either case,

Re: attacking btrfs filesystems via UUID collisions?

On 2015-12-15 09:18, Hugo Mills wrote: On Tue, Dec 15, 2015 at 08:54:01AM -0500, Austin S. Hemmelgarn wrote: On 2015-12-14 16:26, Chris Murphy wrote: On Mon, Dec 14, 2015 at 6:23 AM, Austin S. Hemmelgarn wrote: Agreed, if yo9u can't substantiate _why_ it's bad

Re: [PATCH v3] btrfs: Introduce new mount option to disable tree log replay

On Wed, 2015-12-16 at 09:36 +0800, Qu Wenruo wrote: > One sad example is, we can't use 'norecovery' mount option to disable > log replay in btrfs, as there is 'recovery' mount option already. I think "norecovery" would anyway not really fit... the name should rather indicated, that from the

Re: ERROR: did not find source subvol

On Tue, Dec 15, 2015 at 5:35 PM, Chris Murphy wrote: > kernel 4.2.6-301.fc23.x86_64 > btrfs-progs-4.2.2-1.fc23.x86_64 > > This is a new one for me. Two new Btrfs volumes (one single profile, > one 2x raid1) both created with this btrfs-progs. And then > > [root@f23a