Re: Question: raid1 behaviour on failure

PDF doc info dates it at 23/1/2013, which is the best guess that can easily be found. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Question: raid1 behaviour on failure

Am 26.04.2016 um 18:42 schrieb Holger Hoffstätte: > On 04/26/16 18:19, Henk Slager wrote: >> It looks like a JMS567 + SATA port multipliers behaind it are used in >> this drivebay. The command lsusb -v could show that. So your HW >> setup is like JBOD, not RAID. > > I hate to quote the

Re: Question: raid1 behaviour on failure

Am 26.04.2016 um 18:19 schrieb Henk Slager: > It looks like a JMS567 + SATA port multipliers behaind it are used in > this drivebay. The command lsusb -v could show that. So your HW > setup is like JBOD, not RAID. Here is the output of lsusb -v: Bus 003 Device 004: ID 152d:0567 JMicron

[PATCH 2/2] btrfs: add test for replacing a missing device

From: Omar Sandoval Now that _btrfs_get_profile_configs supports replace missing and the kernel doesn't crash when replacing a missing RAID 5/6 device, test it. Based on an earlier test from Wang Yanfeng. Signed-off-by: Omar Sandoval --- tests/btrfs/027 |

[PATCH 1/2] btrfs: add replace missing and replace RAID 5/6 to profile configs

From: Omar Sandoval Replacing and scrubbing RAID 5/6 is now supported on Btrfs. Enable it in _btrfs_get_profile_configs while making it more generic to also support replace missing. Reviewed-by: Eryu Guan Signed-off-by: Omar Sandoval ---

[PATCH 0/2] fstests: btrfs: the lost levels

From: Omar Sandoval Inspired by a conversation a few of us had at LSF about forgotten fstests, I went back and checked if I had let any tests disappear into the ether. Turns out that I did, so here are the tests for Btrfs replace missing that I never got merged, updated with

Re: [PATCH V18 00/18] Allow I/O on blocks whose size is less than page size

On Wednesday 27 Apr 2016 19:15:34 David Sterba wrote: > On Tue, Apr 26, 2016 at 08:48:49PM +0530, Chandan Rajendra wrote: > > On Tuesday 26 Apr 2016 14:54:46 Filipe Manana wrote: > > > Hi Chandan, > > > > > > What does it mean the tests don't pass? Is there absolutely no code > > > changes for

[PATCH 1/2] btrfs: create degraded-RAID1 chunks

When RAID1 is degraded, newer chunks should be degraded-RAID1 chunks instead of single chunks. The bug is because the devs_min for raid1 was wrong it should be 1, instead of 2. Signed-off-by: Anand Jain --- fs/btrfs/volumes.c | 38 +-

[PATCH 2/2] revert: Btrfs: don't consider the missing device when allocating new chunks

This patch reverts the commit 95669976bd7d30ae265db938ecb46a6b7f8cb893 Btrfs: don't consider the missing device when allocating new chunks Original code was correct as in the deleted comments /* * we add in the count of missing devices because we want * to make sure that any RAID levels on a

[PATCH 0/2] [RFC] btrfs: create degraded-RAID1 chunks

>From the comments that commit[1] deleted - /* - * we add in the count of missing devices because we want - * to make sure that any RAID levels on a degraded FS - * continue to be honored. - * appear to me that automatic reduced-chunk-allocation when RAID1 is degraded wasn't in the original

Re: ...in the matter of partition size

On Wed, Apr 27, 2016 at 8:51 PM, Chris Murphy wrote: > On Wed, Apr 27, 2016 at 2:18 PM, Juan Alberto Cirez > wrote: >> Quick question: Supposed I have n-number of storage pods (physical >> servers with n-number of physical hhds). The end deployment

Re: ...in the matter of partition size

On Wed, Apr 27, 2016 at 2:18 PM, Juan Alberto Cirez wrote: > Quick question: Supposed I have n-number of storage pods (physical > servers with n-number of physical hhds). The end deployment will be > btrfs at the brick/block level with a distributed file system on top. >

Re: ...in the matter of partition size

Juan Alberto Cirez posted on Wed, 27 Apr 2016 14:18:27 -0600 as excerpted: > Quick question: Supposed I have n-number of storage pods (physical > servers with n-number of physical hhds). The end deployment will be > btrfs at the brick/block level with a distributed file system on top. > Keeping

[PATCH RFC v1.1 02/16] btrfs-progs: fsck: Introduce function to check data backref in extent tree

From: Lu Fengqi Introduce a new function check_data_extent_item() to check if the corresponding data backref exists in extent tree. Signed-off-by: Lu Fengqi Signed-off-by: Qu Wenruo --- Changelog: v1.1: Fix a typo

[PATCH v3 1/3] fs: direct-io: handle error in dio_end_io()

If error is passed to dio_end_io(), it should have been dealt with. Unfortunately current code just ignores that silently. Only btrfs uses dio_end_io(). Signed-off-by: Ming Lei --- fs/direct-io.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/direct-io.c

[PATCH v3 3/3] block: avoid to call .bi_end_io() recursively

There were reports about heavy stack use by recursive calling .bi_end_io()([1][2][3]). For example, more than 16K stack is consumed in a single bio complete path[3], and in [2] stack overflow can be triggered if 20 nested dm-crypt is used. Also patches[1] [2] [3] were posted for addressing the

[PATCH v3 2/3] fs: direct-io: call .bi_end_io via bio_endio()

bio_endio() is the graceful way to complete one bio. Signed-off-by: Ming Lei --- fs/direct-io.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/fs/direct-io.c b/fs/direct-io.c index a8dd60a..0a35e51 100644 --- a/fs/direct-io.c +++

[PATCH v3 0/3] block: avoid to call .bi_end_io() recursively

Hi, The 1st patch handles bio error in dio_end_io() which is only used by btrfs. The 2nd patch uses bio_endio() to call .bi_end_io() in dio_end_io(). The 3rd patch avoids to call .bi_end_io recursively in complete path. xfstests(-g auto) is run over ext4, xfs and btrfs with this patchset and

Re: [PATCH] Btrfs: fix qgroup accounting when snapshotting

Josef Bacik wrote on 2016/04/27 11:18 -0400: On 04/26/2016 09:19 PM, Qu Wenruo wrote: Josef Bacik wrote on 2016/04/26 10:24 -0400: The new qgroup stuff needs the quota accounting to be run before doing the inherit, unfortunately they need the commit root switch to happen at a specific time

Re: [PATCH] btrfs: do not return EBUSY on concurrent subvolume mounts

On Wed, Apr 27, 2016 at 05:14:36PM +0200, David Sterba wrote: > A user reported mount failures with EBUSY during boot, there's root > partition and many subvolumes, mounted via /etc/fstab. > > The failure depends on timing, when multiple subvolumes reach the code > between superblock creation in

Re: Add device while rebalancing

On Wed, Apr 27, 2016 at 5:22 AM, Austin S. Hemmelgarn wrote: > On 2016-04-26 20:58, Chris Murphy wrote: >> >> On Tue, Apr 26, 2016 at 5:44 AM, Juan Alberto Cirez >> wrote: >>> >>> >>> With GlusterFS as a distributed volume, the files are already

Re: [PATCH] Btrfs: remove BUG_ON()'s in btrfs_map_block

On Thu, Apr 14, 2016 at 10:16:36AM +0800, Anand Jain wrote: > > - BUG_ON(offset < stripe_offset); > > + if (offset < stripe_offset) { > > + btrfs_crit(fs_info, "stripe math has gone wrong, " > > + "stripe_offset=%llu, offset=%llu, start=%llu, " > > > > +

Re: [bug] df returns 100% used for empty mixed block group filesystem

On Thu, Mar 10, 2016 at 06:40:54PM +0100, David Sterba wrote: > On Thu, Mar 10, 2016 at 01:33:34PM +0500, Roman Mamedov wrote: > > On Thu, 10 Mar 2016 01:24:44 -0700 > > Chris Murphy wrote: > > > > > kernel 4.5.0 rc7 > > > btrfs-progs-4.4.1-1 > > > > > > Summary: A new

Re: [PATCH 2/2] mm, debug: report when GFP_NO{FS,IO} is used explicitly from memalloc_no{fs,io}_{save,restore} context

On Wed, Apr 27, 2016 at 10:03:11AM +0200, Michal Hocko wrote: > On Wed 27-04-16 08:58:45, Dave Chinner wrote: > > On Tue, Apr 26, 2016 at 01:56:12PM +0200, Michal Hocko wrote: > > > From: Michal Hocko > > > > > > THIS PATCH IS FOR TESTING ONLY AND NOT MEANT TO HIT LINUS TREE > >

Re: [PATCH 0/8] btrfs: uapi migration for user-visible API components

On Fri, Apr 01, 2016 at 04:14:22PM -0400, Jeff Mahoney wrote: > The only part of this set that isn't just a direct cut-and-paste is > the last one which converts u8 and u64 values to __u8 and __u64 since > the former aren't exported via include/uapi. > > The goal is that everything required to

Re: [PATCH] Btrfs: track transid for delayed ref flushing

On Wed, Apr 27, 2016 at 09:59:38AM -0400, Chris Mason wrote: > > @@ -2854,9 +2855,16 @@ static void delayed_ref_async_start(struct > > btrfs_work *work) > > > > async = container_of(work, struct async_delayed_refs, work); > > > > - trans = btrfs_join_transaction(async->root); > > +

Re: [PATCH 1.2/2] mm: introduce memalloc_nofs_{save,restore} API

OK, so the lockdep splats I was seeing [1] were much easier to fix than I originally thought. So the following should be folded into the original patch. I will send the full patch later on. [1] http://lkml.kernel.org/r/20160427200927.gc22...@dhcp22.suse.cz --- >From

Re: [PATCH 8/8] btrfs: uapi/linux/btrfs_tree.h, use __u8 and __u64

On Fri, Apr 01, 2016 at 04:14:30PM -0400, Jeff Mahoney wrote: > u8 and u64 aren't exported to userspace, while __u8 and __u64 are. > Reviewed-by: Liu Bo Thanks, -liubo > Signed-off-by: Jeff Mahoney > --- > include/uapi/linux/btrfs_tree.h | 52 >

Re: [PATCH 7/8] btrfs: uapi/linux/btrfs_tree.h migration, item types and defines

On Fri, Apr 01, 2016 at 04:14:29PM -0400, Jeff Mahoney wrote: > The BTRFS_IOC_SEARCH_TREE ioctl returns file system items directly > to userspace. In order to decode them, full type information is required. > > Create a new header, btrfs_tree to contain these since most users won't > need them.

Re: [PATCH 5/8] btrfs: uapi/linux/btrfs.h migration, move balance flags

On Fri, Apr 01, 2016 at 04:14:27PM -0400, Jeff Mahoney wrote: > The BTRFS_BALANCE_* flags are used by struct btrfs_ioctl_balance_args.flags > and btrfs_ioctl_balance_args.{data,meta,sys}.flags in the BTRFS_IOC_BALANCE > ioctl. > Reviewed-by: Liu Bo Thanks, -liubo >

Re: [PATCH 4/8] btrfs: uapi/linux/btrfs.h migration, move feature flags

On Fri, Apr 01, 2016 at 04:14:26PM -0400, Jeff Mahoney wrote: > The compat/compat_ro/incompat feature flags are used by the feature set/get > ioctls. > Reviewed-by: Liu Bo Thanks, -liubo > Signed-off-by: Jeff Mahoney > --- > fs/btrfs/ctree.h

Re: [PATCH 1.2/2] mm: introduce memalloc_nofs_{save,restore} API

On Wed 27-04-16 22:09:27, Michal Hocko wrote: [...] > [ 53.993480] [] mark_held_locks+0x5e/0x74 > [ 53.993480] [] lockdep_trace_alloc+0xb2/0xb5 > [ 53.993480] [] kmem_cache_alloc+0x36/0x2b0 Scratch that. I got it. It is the lockdep annotation which I got wrong with my patch. I thought

Re: [PATCH 3/8] btrfs: uapi/linux/btrfs.h migration, document subvol flags

On Fri, Apr 01, 2016 at 04:14:25PM -0400, Jeff Mahoney wrote: > Signed-off-by: Jeff Mahoney Looks good to me. Reviewed-by: Liu Bo Thanks, -liubo > --- > include/uapi/linux/btrfs.h | 17 ++--- > 1 file changed, 14 insertions(+), 3

...in the matter of partition size

Quick question: Supposed I have n-number of storage pods (physical servers with n-number of physical hhds). The end deployment will be btrfs at the brick/block level with a distributed file system on top. Keeping in mind that my overriding goal is to have high availability and the mechanism

Re: [PATCH 1.2/2] mm: introduce memalloc_nofs_{save,restore} API

Hi Dave, On Wed 27-04-16 13:54:35, Michal Hocko wrote: [...] > diff --git a/fs/xfs/kmem.h b/fs/xfs/kmem.h > index 0d83f332e5c2..b35688a54c9a 100644 > --- a/fs/xfs/kmem.h > +++ b/fs/xfs/kmem.h > @@ -50,7 +50,7 @@ kmem_flags_convert(xfs_km_flags_t flags) > lflags = GFP_ATOMIC |

Re: [PATCH 1.1/2] xfs: abstract PF_FSTRANS to PF_MEMALLOC_NOFS

On Wed 27-04-16 11:41:51, Andreas Dilger wrote: > On Apr 27, 2016, at 5:54 AM, Michal Hocko wrote: [...] > > --- a/fs/xfs/kmem.c > > +++ b/fs/xfs/kmem.c > > @@ -80,13 +80,13 @@ kmem_zalloc_large(size_t size, xfs_km_flags_t flags) > > * context via PF_MEMALLOC_NOIO to

Re: [PATCH 0/8] btrfs: uapi migration for user-visible API components

On 04/01/2016 04:14 PM, Jeff Mahoney wrote: commit 55e301fd57a (Btrfs: move fs/btrfs/ioctl.h to include/uapi/linux/btrfs.h) was intended to make the ioctl definitions available to userspace. Unfortunately, moving just that file wasn't enough and many of the ioctls aren't actually usable without

Re: [PATCH] btrfs: do not return EBUSY on concurrent subvolume mounts

On 04/27/2016 11:14 AM, David Sterba wrote: A user reported mount failures with EBUSY during boot, there's root partition and many subvolumes, mounted via /etc/fstab. The failure depends on timing, when multiple subvolumes reach the code between superblock creation in RO mode, while the

Re: [PATCH 2/8] btrfs: uapi/linux/btrfs.h migration, qgroup limit flags

On Fri, Apr 01, 2016 at 04:14:24PM -0400, Jeff Mahoney wrote: > The BTRFS_QGROUP_LIMIT_* flags are required to tell the kernel which > fields are valid when using the BTRFS_IOC_QGROUP_LIMIT ioctl. Looks good to me. Reviewed-by: Liu Bo Thanks, -liubo > > Signed-off-by:

Re: [PATCH 1/8] btrfs: uapi/linux/btrfs.h migration, move BTRFS_LABEL_SIZE

On Fri, Apr 01, 2016 at 04:14:23PM -0400, Jeff Mahoney wrote: > BTRFS_LABEL_SIZE is required to define the BTRFS_IOC_GET_FSLABEL and > BTRFS_IOC_SET_FSLABEL ioctls. Reviewed-by: Liu Bo Thanks, -liubo > > Signed-off-by: Jeff Mahoney > --- >

Re: [PATCH 1.1/2] xfs: abstract PF_FSTRANS to PF_MEMALLOC_NOFS

On Apr 27, 2016, at 5:54 AM, 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.

Re: [PATCH] Btrfs: fix divide error upon chunk's stripe_len

On Wed, Apr 27, 2016 at 10:23:35AM -0700, Liu Bo wrote: > On Wed, Apr 27, 2016 at 06:39:03PM +0200, David Sterba wrote: > > On Tue, Apr 26, 2016 at 05:53:31PM -0700, Liu Bo wrote: > > > The struct 'map_lookup' uses type int for @stripe_len, while > > > btrfs_chunk_stripe_len() can return a u64

Re: [PATCH] Btrfs: fix divide error upon chunk's stripe_len

On Wed, Apr 27, 2016 at 06:39:03PM +0200, David Sterba wrote: > On Tue, Apr 26, 2016 at 05:53:31PM -0700, Liu Bo wrote: > > The struct 'map_lookup' uses type int for @stripe_len, while > > btrfs_chunk_stripe_len() can return a u64 value, and it may end up with > > @stripe_len being undefined value

Re: Add device while rebalancing

On 04/27/16 18:40, Juan Alberto Cirez wrote: > If this is so, then it leaves even confused. I was under the > impression that the driving imperative for the creation of btrfs was > to address the shortcomings of current filesystems (within the context > of distributed data). That the idea was to

Re: [PATCH V18 00/18] Allow I/O on blocks whose size is less than page size

On Tue, Apr 26, 2016 at 11:22:14AM -0400, Josef Bacik wrote: > > TODO: > > 1. The selftests code needs to be fixed to work in subpage-blocksize > >scenario. I have currently disabled self-tests from my kernel > >configuration. We can expect an mail from kbuild indicating a > >build

Re: [PATCH V18 00/18] Allow I/O on blocks whose size is less than page size

On Tue, Apr 26, 2016 at 08:48:49PM +0530, Chandan Rajendra wrote: > On Tuesday 26 Apr 2016 14:54:46 Filipe Manana wrote: > > > Hi Chandan, > > > > What does it mean the tests don't pass? Is there absolutely no code > > changes for scrub and compression, or there is but still needs more > >

Re: Add device while rebalancing

Holger, If this is so, then it leaves even confused. I was under the impression that the driving imperative for the creation of btrfs was to address the shortcomings of current filesystems (within the context of distributed data). That the idea was to create a low level filesystem that would be

Re: Add device while rebalancing

Holger, If this is so, then it leaves with even confused. I was under the impression that the driving imperative for the creation of btrfs was to address the shortcomings of current filesystem within the context of distributed data. That the idea was to create a low level filesystem that would the

Re: [PATCH] Btrfs: fix divide error upon chunk's stripe_len

On Tue, Apr 26, 2016 at 05:53:31PM -0700, Liu Bo wrote: > The struct 'map_lookup' uses type int for @stripe_len, while > btrfs_chunk_stripe_len() can return a u64 value, and it may end up with > @stripe_len being undefined value and it can lead to 'divide error' in > __btrfs_map_block(). > >

Re: Add device while rebalancing

On 04/27/16 17:58, Juan Alberto Cirez wrote: > Correct me if I'm wrong but the sum total of the above seems to > suggest (at first glance) that BRTFS add several layers of complexity, > but for little real benefit (at least in the case use of btrfs at the > brick layer with a distributed

Re: Add device while rebalancing

WOW! Correct me if I'm wrong but the sum total of the above seems to suggest (at first glance) that BRTFS add several layers of complexity, but for little real benefit (at least in the case use of btrfs at the brick layer with a distributed filesystem on top)... "...I've always though it'd be

Re: [PATCH] Btrfs: fix qgroup accounting when snapshotting

On 04/26/2016 09:19 PM, Qu Wenruo wrote: Josef Bacik wrote on 2016/04/26 10:24 -0400: The new qgroup stuff needs the quota accounting to be run before doing the inherit, unfortunately they need the commit root switch to happen at a specific time for this to work properly. Fix this by

[PATCH] btrfs: do not return EBUSY on concurrent subvolume mounts

A user reported mount failures with EBUSY during boot, there's root partition and many subvolumes, mounted via /etc/fstab. The failure depends on timing, when multiple subvolumes reach the code between superblock creation in RO mode, while the subvolumes are RW. This discrepancy leads to EBUSY

Re: [PATCH V18 01/18] Btrfs: subpage-blocksize: Fix whole page read.

On 04/27/2016 01:24 AM, Chandan Rajendra wrote: On Tuesday 26 Apr 2016 11:51:22 Josef Bacik wrote: +int set_page_extent_mapped(struct page *page) { + struct btrfs_page_private *pg_private; + if (!PagePrivate(page)) { + pg_private = kzalloc(sizeof(*pg_private),

Re: [PATCH v3 2/2] Btrfs: don't do unnecessary delalloc flushes when relocating

On 04/26/2016 01:45 PM, fdman...@kernel.org wrote: From: Filipe Manana Before we start the actual relocation process of a block group, we do calls to flush delalloc of all inodes and then wait for ordered extents to complete. However we do these flush calls just to make sure

Re: [PATCH] Btrfs: track transid for delayed ref flushing

On Mon, Apr 11, 2016 at 05:37:40PM -0400, Josef Bacik wrote: > Using the offwakecputime bpf script I noticed most of our time was spent > waiting > on the delayed ref throttling. This is what is supposed to happen, but > sometimes the transaction can commit and then we're waiting for throttling

Re: 4.6.0-rc3+: WARNING: CPU: 16 PID: 17257 at fs/btrfs/inode.c:9261 btrfs_destroy_inode

On Wed, Apr 27, 2016 at 02:25:50PM +0200, Christian Borntraeger wrote: > Folks, > > I can sometimes trigger the following bug > > [ 244.493534] [ cut here ] > [ 244.493624] WARNING: CPU: 16 PID: 17257 at fs/btrfs/inode.c:9261 > btrfs_destroy_inode+0x288/0x2b0 [btrfs] >

Re: [PATCH 1.2/2] mm: introduce memalloc_nofs_{save,restore} API

On Wed 27-04-16 13:54:35, Michal Hocko wrote: > From: Michal Hocko > Ups missed Dave's note about: > GFP_NOFS context is used for the following 4 reasons currently > - to prevent from deadlocks when the lock held by the allocation > context would be needed during

4.6.0-rc3+: WARNING: CPU: 16 PID: 17257 at fs/btrfs/inode.c:9261 btrfs_destroy_inode

Folks, I can sometimes trigger the following bug [ 244.493534] [ cut here ] [ 244.493624] WARNING: CPU: 16 PID: 17257 at fs/btrfs/inode.c:9261 btrfs_destroy_inode+0x288/0x2b0 [btrfs] [ 244.493626] Kernel panic - not syncing: panic_on_warn set ... [ 244.493629] CPU:

Re: Install to or Recover RAID Array Subvolume Root?

Hi David, Thanks for the update, sorry for the delay, this email was sitting in my drafts folder. Instructions follow. On 26 April 2016 at 05:23, David Alcorn wrote: > > Nicholas: > > 1. My RAID array is partially filled and backed up. > 2. I prefer to mount by UUID. > 3.

[PATCH 1.2/2] mm: introduce memalloc_nofs_{save,restore} API

From: Michal Hocko GFP_NOFS context is used for the following 4 reasons currently - to prevent from deadlocks when the lock held by the allocation context would be needed during the memory reclaim - to prevent from stack overflows during the reclaim

[PATCH 1.1/2] xfs: abstract PF_FSTRANS to PF_MEMALLOC_NOFS

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 a more genric name PF_MEMALLOC_NOFS which is in line

Re: Add device while rebalancing

On 2016-04-26 20:58, Chris Murphy wrote: On Tue, Apr 26, 2016 at 5:44 AM, Juan Alberto Cirez wrote: With GlusterFS as a distributed volume, the files are already spread among the servers causing file I/O to be spread fairly evenly among them as well, thus probably

Re: empty disk reports full

Alejandro Vargas posted on Wed, 27 Apr 2016 11:29:31 +0200 as excerpted: >> Also there are two compress mount options that conflict with each >> other, is this intentional? > > I did not thought that compress and compress-force are incompatible... > The intention is to force it to compress the

Re: Add device while rebalancing

Chris Murphy posted on Tue, 26 Apr 2016 18:58:06 -0600 as excerpted: > On Tue, Apr 26, 2016 at 5:44 AM, Juan Alberto Cirez > wrote: >> RAID10 configuration, on the other hand, requires a minimum of four >> HDD, but it stripes data across mirrored pairs. As long as one

Re: empty disk reports full

El Martes, 26 de abril de 2016 00:08:49 Chris Murphy escribió: > > [root@backups ~]# btrfs fi df /mnt/backup > > Data, single: total=1.79TiB, used=1.78TiB > > System, DUP: total=32.00MiB, used=240.00KiB > > Metadata, DUP: total=17.00GiB, used=15.55GiB > > GlobalReserve, single: total=512.00MiB,

Re: [PATCH 2/2] mm, debug: report when GFP_NO{FS,IO} is used explicitly from memalloc_no{fs,io}_{save,restore} context

On Wed 27-04-16 08:58:45, Dave Chinner wrote: > On Tue, Apr 26, 2016 at 01:56:12PM +0200, Michal Hocko wrote: > > 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

Re: [PATCH 1/2] mm: add PF_MEMALLOC_NOFS

On Wed 27-04-16 09:07:02, Dave Chinner wrote: > On Tue, Apr 26, 2016 at 01:56:11PM +0200, Michal Hocko wrote: > > From: Michal Hocko > > > > GFP_NOFS context is used for the following 4 reasons currently > > - to prevent from deadlocks when the lock held by the allocation >