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,
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
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:
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
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
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
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
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?
__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
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
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
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:
__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
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
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
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
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
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
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:
>
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
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
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
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);
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
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
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
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
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
... 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.
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
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
>
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,
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
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
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
35 matches
Mail list logo