On 12/17/2016 12:48 AM, John L. Center wrote:
> Hi,
>
> I ran a btrfs scrub & found 3 uncorrectable errors:
>
> [...]
> When I ran scrub again, I still had
> 1 uncorrectable error, but noticed that btrfs wrote to dmesg that 4 were
> found:
>
> [61530.256323] BTRFS warning (device md126p2): check
On Fri 16-12-16 19:47:00, Nils Holland wrote:
[...]
> Despite the fact that I'm no expert, I can see that there's no more
> GFP_NOFS being logged, which seems to be what the patches tried to
> achieve. What the still present OOMs mean remains up for
> interpretation by the experts, all I can say is
Hi,
I ran a btrfs scrub & found 3 uncorrectable errors:
[ 5461.412007] BTRFS warning (device md126p2): checksum error at logical
193296359424 on dev /dev/md126p2, sector 379645488, root 257, inode
1795724, offset 217088, length 4096, links 1 (path:
usr/lib/x86_64-linux-gnu/tracker-1.0/libtracker-
On Fri 16-12-16 17:47:25, Chris Mason wrote:
> On 12/16/2016 05:14 PM, Michal Hocko wrote:
> > On Fri 16-12-16 13:15:18, Chris Mason wrote:
> > > On 12/16/2016 02:39 AM, Michal Hocko wrote:
> > [...]
> > > > I believe the right way to go around this is to pursue what I've started
> > > > in [1]. I
Hello,
After my backup drive displayed a weird issue (programs accessing it suddenly
started zombifying, but it worked fine after a reboot), I decided to check the
file system. The initial results with btrfs-check's low-memory mode found
reference count mismatches, but that seems to have been
On 12/16/2016 05:14 PM, Michal Hocko wrote:
On Fri 16-12-16 13:15:18, Chris Mason wrote:
On 12/16/2016 02:39 AM, Michal Hocko wrote:
[...]
I believe the right way to go around this is to pursue what I've started
in [1]. I will try to prepare something for testing today for you. Stay
tuned. But
On Fri, Dec 02, 2016 at 12:25:19PM +, Filipe Manana wrote:
> On Fri, Dec 2, 2016 at 1:41 AM, Liu Bo wrote:
> > On Thu, Nov 24, 2016 at 11:13:37AM +, Filipe Manana wrote:
> >> On Wed, Nov 23, 2016 at 9:22 PM, Liu Bo wrote:
...
> >>
> >> The analysis is correct Bo.
> >> Originally to fix ra
On Fri 16-12-16 13:15:18, Chris Mason wrote:
> On 12/16/2016 02:39 AM, Michal Hocko wrote:
[...]
> > I believe the right way to go around this is to pursue what I've started
> > in [1]. I will try to prepare something for testing today for you. Stay
> > tuned. But I would be really happy if somebod
On Fri 16-12-16 12:31:51, Johannes Weiner wrote:
> On Fri, Dec 16, 2016 at 04:58:08PM +0100, Michal Hocko wrote:
> > @@ -1013,7 +1013,7 @@ bool out_of_memory(struct oom_control *oc)
> > * make sure exclude 0 mask - all other users should have at least
> > * ___GFP_DIRECT_RECLAIM to get he
On Fri 16-12-16 11:37:50, Brian Foster wrote:
> On Fri, Dec 16, 2016 at 04:40:41PM +0100, Michal Hocko wrote:
> > Updated patch after Mike noticed a BUG_ON when KM_NOLOCKDEP is used.
> > ---
> > From 1497e713e11639157aef21cae29052cb3dc7ab44 Mon Sep 17 00:00:00 2001
> > From: Michal Hocko
> > Date:
On Fri 16-12-16 11:38:11, Brian Foster wrote:
> On Thu, Dec 15, 2016 at 03:07:11PM +0100, Michal Hocko wrote:
[...]
> > @@ -459,7 +459,7 @@ _xfs_buf_map_pages(
> > break;
> > vm_unmap_aliases();
> > } while (retried++ <= 1);
> > -
On Fri, Dec 16, 2016 at 10:53:48AM -0800, Liu Bo wrote:
> On Fri, Dec 16, 2016 at 10:44:11AM -0500, Jeff Mahoney wrote:
> > On 12/16/16 4:18 AM, Adam Borowski wrote:
> > > Got a 100% reproducible splat on 4.9.
> > >
> > > So I plopped in a fresh 4TB disk:
> > >
> > > dd if=/dev/zero of=meow bs=1
On 12/16/2016 02:39 AM, Michal Hocko wrote:
[CC linux-mm and btrfs guys]
On Thu 15-12-16 23:57:04, Nils Holland wrote:
[...]
Of course, none of this are workloads that are new / special in any
way - prior to 4.8, I never experienced any issues doing the exact
same things.
Dec 15 19:02:16 teela
On Fri, Dec 16, 2016 at 04:58:06PM +0100, Michal Hocko wrote:
> On Fri 16-12-16 08:39:41, Michal Hocko wrote:
> [...]
> > That being said, the OOM killer invocation is clearly pointless and
> > pre-mature. We normally do not invoke it normally for GFP_NOFS requests
> > exactly for these reasons. Bu
On Fri, Dec 16, 2016 at 10:44:11AM -0500, Jeff Mahoney wrote:
> On 12/16/16 4:18 AM, Adam Borowski wrote:
> > Got a 100% reproducible splat on 4.9.
> >
> > So I plopped in a fresh 4TB disk:
> >
> > dd if=/dev/zero of=meow bs=1 seek=4000785104895 count=1
> > mkfs -t btrfs meow
> > mount -onoatime
On 12/16/2016 02:39 AM, Michal Hocko wrote:
[CC linux-mm and btrfs guys]
On Thu 15-12-16 23:57:04, Nils Holland wrote:
[...]
Of course, none of this are workloads that are new / special in any
way - prior to 4.8, I never experienced any issues doing the exact
same things.
Dec 15 19:02:16 teela
Hi Linus,
My for-linus-4.10 branch has our merge window fun:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
for-linus-4.10
There is a trivial conflict with your current git, my resolution is
here:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
for-lin
On Fri, Dec 16, 2016 at 04:58:08PM +0100, Michal Hocko wrote:
> @@ -1013,7 +1013,7 @@ bool out_of_memory(struct oom_control *oc)
>* make sure exclude 0 mask - all other users should have at least
>* ___GFP_DIRECT_RECLAIM to get here.
>*/
> - if (oc->gfp_mask && !(oc->gfp
cleaned up the file with checkpatch
Signed-off-by: Philippe Loctaux
---
fs/btrfs/file.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index 3a14c87..d131b8d 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -4
On Thu, Dec 15, 2016 at 03:07:09PM +0100, Michal Hocko wrote:
> From: Michal Hocko
>
> xfs has defined PF_FSTRANS to declare a scope GFP_NOFS semantic quite
> some time ago. We would like to make this concept more generic and use
> it for other filesystems as well. Let's start by giving the flag
On Thu, Dec 15, 2016 at 03:07:11PM +0100, Michal Hocko wrote:
> From: Michal Hocko
>
> kmem_zalloc_large and _xfs_buf_map_pages use memalloc_noio_{save,restore}
> API to prevent from reclaim recursion into the fs because vmalloc can
> invoke unconditional GFP_KERNEL allocations and these function
On Fri, Dec 16, 2016 at 04:40:41PM +0100, Michal Hocko wrote:
> Updated patch after Mike noticed a BUG_ON when KM_NOLOCKDEP is used.
> ---
> From 1497e713e11639157aef21cae29052cb3dc7ab44 Mon Sep 17 00:00:00 2001
> From: Michal Hocko
> Date: Thu, 15 Dec 2016 13:06:43 +0100
> Subject: [PATCH] xfs: i
On Fri, 2016-12-16 at 16:35 +0100, Michal Hocko wrote:
> On Fri 16-12-16 16:05:58, Mike Galbraith wrote:
> > On Thu, 2016-12-15 at 15:07 +0100, Michal Hocko wrote:
> > > Hi,
> > > I have posted the previous version here [1]. Since then I have added a
> > > support to suppress reclaim lockdep warnin
From: Michal Hocko
__alloc_pages_may_oom makes sure to skip the OOM killer depending on
the allocation request. This includes lowmem requests, costly high
order requests and others. For a long time __GFP_NOFAIL acted as an
override for all those rules. This is not documented and it can be quite
s
From: Michal Hocko
Tetsuo Handa has pointed out that 0a0337e0d1d1 ("mm, oom: rework oom
detection") has subtly changed semantic for costly high order requests
with __GFP_NOFAIL and withtout __GFP_REPEAT and those can fail right now.
My code inspection didn't reveal any such users in the tree but
On Fri 16-12-16 08:39:41, Michal Hocko wrote:
[...]
> That being said, the OOM killer invocation is clearly pointless and
> pre-mature. We normally do not invoke it normally for GFP_NOFS requests
> exactly for these reasons. But this is GFP_NOFS|__GFP_NOFAIL which
> behaves differently. I am about
On 12/16/16 7:20 AM, Colin King wrote:
> From: Colin Ian King
>
> inode is being deferenced and then inode is checked to see if it
> is null, implying we potentially could have a null pointer deference
> on inode.
>
> Found with static analysis by CoverityScan, CID 1389472
>
> Fix this by deref
On 12/16/16 4:18 AM, Adam Borowski wrote:
> Got a 100% reproducible splat on 4.9.
>
> So I plopped in a fresh 4TB disk:
>
> dd if=/dev/zero of=meow bs=1 seek=4000785104895 count=1
> mkfs -t btrfs meow
> mount -onoatime meow /mnt/vol1
> cd /mnt/vol1
> btrfs subv create foo
Hi Adam -
The check h
Updated patch after Mike noticed a BUG_ON when KM_NOLOCKDEP is used.
---
>From 1497e713e11639157aef21cae29052cb3dc7ab44 Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Thu, 15 Dec 2016 13:06:43 +0100
Subject: [PATCH] xfs: introduce and use KM_NOLOCKDEP to silence reclaim
lockdep false positives
On Fri 16-12-16 16:05:58, Mike Galbraith wrote:
> On Thu, 2016-12-15 at 15:07 +0100, Michal Hocko wrote:
> > Hi,
> > I have posted the previous version here [1]. Since then I have added a
> > support to suppress reclaim lockdep warnings (__GFP_NOLOCKDEP) to allow
> > removing GFP_NOFS usage motivat
From: Colin Ian King
The check for a null inode is redundant since the function
is a callback for exportfs, which will itself crash if
dentry->d_inode or parent->d_inode is NULL. Removing the
null check makes this consistent with other file systems.
Found with static analysis by CoverityScan, C
On 16/12/16 15:03, Jeff Mahoney wrote:
> On 12/16/16 7:20 AM, Colin King wrote:
>> From: Colin Ian King
>>
>> inode is being deferenced and then inode is checked to see if it
>> is null, implying we potentially could have a null pointer deference
>> on inode.
>>
>> Found with static analysis by Co
On Thu, 2016-12-15 at 15:07 +0100, Michal Hocko wrote:
> Hi,
> I have posted the previous version here [1]. Since then I have added a
> support to suppress reclaim lockdep warnings (__GFP_NOLOCKDEP) to allow
> removing GFP_NOFS usage motivated by the lockdep false positives. On top
> of that I've t
I am hoping you can help or inform me if the following is a vain hope.
I have mistakenly deleted all files from a pair of disks formated into
a btrfs system. (pressed the wrong function key on midnight
commander in error!). I have not written anything to the disks since
the deletion, and
From: Michal Hocko
THIS PATCH IS FOR TESTING ONLY AND NOT MEANT TO HIT LINUS TREE
It is desirable to reduce the direct GFP_NO{FS,IO} usage at minimum and
prefer scope usage defined by memalloc_no{fs,io}_{save,restore} API.
Let's help this process and add a debugging tool to catch when an
explic
Hi,
I've forgot to add the following two patches which should help to
identify explicit GFP_NO{FS,IO} usage from withing a scope context. Such
a usage can be changed to the full GFP_KERNEL because all the calls
from within the NO{FS,IO} scope will drop the __GFP_FS resp. __GFP_IO
automatically and
From: Michal Hocko
THIS PATCH IS FOR TESTING ONLY AND NOT MEANT TO HIT LINUS TREE
There are some code paths used by all the filesystems which we cannot
change to drop the GFP_NOFS, yet they generate a lot of warnings.
Provide {disable,enable}_scope_gfp_check to silence those.
alloc_page_buffers
From: Colin Ian King
inode is being deferenced and then inode is checked to see if it
is null, implying we potentially could have a null pointer deference
on inode.
Found with static analysis by CoverityScan, CID 1389472
Fix this by dereferencing inode only after the inode null check.
Fixes: 0
--
Az e-mail ID nyerte € 150,000.00 euró (Száz és ötvenezer euró) LottoMax
Nemzetközi Jótékonysági program.Ref Nem Sp
/179/0-39/44/4-07/ES.Lucky No.9 / 44/15/27 / 49.For több információt és
eljárást építettek, kérjük lépjen kapcsolatba az ügynök össze;
Nemzeti irányítószámot AGENCY.S.L
Mr.Ja
Got a 100% reproducible splat on 4.9.
So I plopped in a fresh 4TB disk:
dd if=/dev/zero of=meow bs=1 seek=4000785104895 count=1
mkfs -t btrfs meow
mount -onoatime meow /mnt/vol1
cd /mnt/vol1
btrfs subv create foo
[ 104.867344] BTRFS: device label diediedie devid 1 transid 5 /dev/sdc1
[ 127.438
On 12/16/2016 02:11 PM, Chandan Rajendra wrote:
On Thursday, December 15, 2016 05:03:30 PM Qu Wenruo wrote:
Although commit 9c4b820412746b3 tried to make the rollback condition
less restrict, to co-operate with new rollback behavior, it's still too
restrict.
If btrfs allocates a new data chun
41 matches
Mail list logo
