shutdown.
Darrick J. Wong (1):
xfs: defer should abort intent items if the trans roll fails
fs/xfs/libxfs/xfs_defer.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
--
Dave Chinner
da...@fromorbit.com
shutdown.
Darrick J. Wong (1):
xfs: defer should abort intent items if the trans roll fails
fs/xfs/libxfs/xfs_defer.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
--
Dave Chinner
da...@fromorbit.com
til the write cache is filled (can be GB in size) and by then it's
way too late to fix up with OS level queuing...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
til the write cache is filled (can be GB in size) and by then it's
way too late to fix up with OS level queuing...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Thu, Nov 03, 2016 at 04:43:57PM -0400, Theodore Ts'o wrote:
> On Thu, Nov 03, 2016 at 09:48:27AM +1100, Dave Chinner wrote:
> >
> > We're going to need regression tests for this to ensure that it
> > works properly and that we don't inadvertantly break it in future.
&
On Thu, Nov 03, 2016 at 04:43:57PM -0400, Theodore Ts'o wrote:
> On Thu, Nov 03, 2016 at 09:48:27AM +1100, Dave Chinner wrote:
> >
> > We're going to need regression tests for this to ensure that it
> > works properly and that we don't inadvertantly break it in future.
&
On Thu, Nov 03, 2016 at 11:51:02AM -0600, Ross Zwisler wrote:
> On Thu, Nov 03, 2016 at 12:58:26PM +1100, Dave Chinner wrote:
> > On Tue, Nov 01, 2016 at 01:54:02PM -0600, Ross Zwisler wrote:
> > > DAX PMDs have been disabled since Jan Kara introduced DAX radix tree b
On Thu, Nov 03, 2016 at 11:51:02AM -0600, Ross Zwisler wrote:
> On Thu, Nov 03, 2016 at 12:58:26PM +1100, Dave Chinner wrote:
> > On Tue, Nov 01, 2016 at 01:54:02PM -0600, Ross Zwisler wrote:
> > > DAX PMDs have been disabled since Jan Kara introduced DAX radix tree b
ely to be
merged through the ext4 tree, so it needs a stable branch. There's
iomap direct IO patches for XFS pending, and they conflict with this
patchset. i.e. we need a stable git base to work from...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
ely to be
merged through the ext4 tree, so it needs a stable branch. There's
iomap direct IO patches for XFS pending, and they conflict with this
patchset. i.e. we need a stable git base to work from...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
ate that the mount behaviour, clamping and range limiting is
working as intended?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
ate that the mount behaviour, clamping and range limiting is
working as intended?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Tue, Nov 01, 2016 at 06:38:26PM -0700, Hugh Dickins wrote:
> On Wed, 2 Nov 2016, Dave Chinner wrote:
> > On Tue, Nov 01, 2016 at 04:51:30PM -0700, Hugh Dickins wrote:
> > > On Wed, 26 Oct 2016, Jakob Unterwurzacher wrote:
> > >
> > > > tmpfs seems t
On Tue, Nov 01, 2016 at 06:38:26PM -0700, Hugh Dickins wrote:
> On Wed, 2 Nov 2016, Dave Chinner wrote:
> > On Tue, Nov 01, 2016 at 04:51:30PM -0700, Hugh Dickins wrote:
> > > On Wed, 26 Oct 2016, Jakob Unterwurzacher wrote:
> > >
> > > > tmpfs seems t
we need filesystem
level serialisation for this.
Put simple: page locks are insufficient as a generic mechanism for
serialising filesystem operations. The locking required for this is
generally deeply filesystem implementation specific, so it's fine
that the VFS doesn't attempt to provide anything
we need filesystem
level serialisation for this.
Put simple: page locks are insufficient as a generic mechanism for
serialising filesystem operations. The locking required for this is
generally deeply filesystem implementation specific, so it's fine
that the VFS doesn't attempt to provide anything
On Mon, Oct 31, 2016 at 02:07:54PM +0100, Christoph Hellwig wrote:
> On Mon, Oct 31, 2016 at 10:23:31AM +1100, Dave Chinner wrote:
> > This doesn't belong in this patchset.
>
> It does. I can't fix up the calling conventions for a methods that
> was never implemented.
That sou
On Mon, Oct 31, 2016 at 02:07:54PM +0100, Christoph Hellwig wrote:
> On Mon, Oct 31, 2016 at 10:23:31AM +1100, Dave Chinner wrote:
> > This doesn't belong in this patchset.
>
> It does. I can't fix up the calling conventions for a methods that
> was never implemented.
That sou
irst time so when all the bikshedding stops we can convert it to
the One True AIO Interface that is decided on.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
all the bikshedding stops we can convert it to
the One True AIO Interface that is decided on.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
17 files changed, 640 insertions(+), 645 deletions(-)
--
Dave Chinner
da...@fromorbit.com
17 files changed, 640 insertions(+), 645 deletions(-)
--
Dave Chinner
da...@fromorbit.com
and to all slip through the ENOSPC
detection without the correct metadata reservations and all require
multiple metadata blocks to be allocated durign writeback...
If you've got a way to trigger it quickly and reliably, that would
be helpful...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
and to all slip through the ENOSPC
detection without the correct metadata reservations and all require
multiple metadata blocks to be allocated durign writeback...
If you've got a way to trigger it quickly and reliably, that would
be helpful...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Tue, Oct 25, 2016 at 05:50:43AM -0600, Stephen Bates wrote:
> Hi Dave and Christoph
>
> On Fri, Oct 21, 2016 at 10:12:53PM +1100, Dave Chinner wrote:
> > On Fri, Oct 21, 2016 at 02:57:14AM -0700, Christoph Hellwig wrote:
> > > On Fri, Oct 21, 2016 at 10:22:39AM +
On Tue, Oct 25, 2016 at 05:50:43AM -0600, Stephen Bates wrote:
> Hi Dave and Christoph
>
> On Fri, Oct 21, 2016 at 10:12:53PM +1100, Dave Chinner wrote:
> > On Fri, Oct 21, 2016 at 02:57:14AM -0700, Christoph Hellwig wrote:
> > > On Fri, Oct 21, 2016 at 10:22:39AM +
On Mon, Oct 24, 2016 at 01:34:53PM -0700, Dave Hansen wrote:
> On 10/21/2016 03:50 PM, Dave Chinner wrote:
> > On Fri, Oct 21, 2016 at 06:00:07PM +0300, Kirill A. Shutemov wrote:
> >> On Fri, Oct 21, 2016 at 04:01:18PM +1100, Dave Chinner wrote:
> >> To me, most of
On Mon, Oct 24, 2016 at 01:34:53PM -0700, Dave Hansen wrote:
> On 10/21/2016 03:50 PM, Dave Chinner wrote:
> > On Fri, Oct 21, 2016 at 06:00:07PM +0300, Kirill A. Shutemov wrote:
> >> On Fri, Oct 21, 2016 at 04:01:18PM +1100, Dave Chinner wrote:
> >> To me, most of
exists.
Also, I don't think s_shrink.batch = 0 does what you think it does.
The superblock batch size default of 1024 is more efficient than
setting sb->s_shrink.batch = 0 as that makes the shrinker use
SHRINK_BATCH:
#define SHRINK_BATCH 128
i.e. it does less work per batch so has more overhead
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
think s_shrink.batch = 0 does what you think it does.
The superblock batch size default of 1024 is more efficient than
setting sb->s_shrink.batch = 0 as that makes the shrinker use
SHRINK_BATCH:
#define SHRINK_BATCH 128
i.e. it does less work per batch so has more overhead
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Fri, Oct 21, 2016 at 06:00:07PM +0300, Kirill A. Shutemov wrote:
> On Fri, Oct 21, 2016 at 04:01:18PM +1100, Dave Chinner wrote:
> > On Thu, Oct 20, 2016 at 07:01:16PM -0700, Andi Kleen wrote:
> > > > Ugh, no, please don't use mount options for file specific behaviours
&
On Fri, Oct 21, 2016 at 06:00:07PM +0300, Kirill A. Shutemov wrote:
> On Fri, Oct 21, 2016 at 04:01:18PM +1100, Dave Chinner wrote:
> > On Thu, Oct 20, 2016 at 07:01:16PM -0700, Andi Kleen wrote:
> > > > Ugh, no, please don't use mount options for file specific behaviours
&
On Fri, Oct 21, 2016 at 09:25:10AM +0200, Vlastimil Babka wrote:
> On 10/21/2016 12:59 AM, Dave Chinner wrote:
> >On Thu, Oct 20, 2016 at 03:33:58PM +0200, Michal Hocko wrote:
> >>On Thu 20-10-16 14:11:49, Vlastimil Babka wrote:
> >>[...]
> >>> Hi, I'm won
On Fri, Oct 21, 2016 at 09:25:10AM +0200, Vlastimil Babka wrote:
> On 10/21/2016 12:59 AM, Dave Chinner wrote:
> >On Thu, Oct 20, 2016 at 03:33:58PM +0200, Michal Hocko wrote:
> >>On Thu 20-10-16 14:11:49, Vlastimil Babka wrote:
> >>[...]
> >>> Hi, I'm won
On Fri, Oct 21, 2016 at 02:57:14AM -0700, Christoph Hellwig wrote:
> On Fri, Oct 21, 2016 at 10:22:39AM +1100, Dave Chinner wrote:
> > You do realise that local filesystems can silently change the
> > location of file data at any point in time, so there is no such
> > thing
On Fri, Oct 21, 2016 at 02:57:14AM -0700, Christoph Hellwig wrote:
> On Fri, Oct 21, 2016 at 10:22:39AM +1100, Dave Chinner wrote:
> > You do realise that local filesystems can silently change the
> > location of file data at any point in time, so there is no such
> > thing
to use large pages
> would need to be especially enabled. That would seem awfully limiting
> to me and needlessly deny benefits to most existing code.
No change to applications will be necessary (see above), though
there's no reason why couldn't directly use the VFS interfaces to
explicitly ask for such behaviour themselves
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
to use large pages
> would need to be especially enabled. That would seem awfully limiting
> to me and needlessly deny benefits to most existing code.
No change to applications will be necessary (see above), though
there's no reason why couldn't directly use the VFS interfaces to
explicitly ask for such behaviour themselves
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
uot; of file data to block device addresses
in userspace?
If you want remote access to the blocks owned and controlled by a
filesystem, then you need to use a filesystem with a remote locking
mechanism to allow co-ordinated, coherent access to the data in
those blocks. Anything else is just asking for ongoing, unfixable
filesystem corruption or data leakage problems (i.e. security
issues).
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
uot; of file data to block device addresses
in userspace?
If you want remote access to the blocks owned and controlled by a
filesystem, then you need to use a filesystem with a remote locking
mechanism to allow co-ordinated, coherent access to the data in
those blocks. Anything else is just asking for ongoing, unfixable
filesystem corruption or data leakage problems (i.e. security
issues).
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
can grow to gigabytes in size
under various metadata intensive workloads, there's every chance
that such reporting will make users incorrectly think they have a
massive memory leak
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
can grow to gigabytes in size
under various metadata intensive workloads, there's every chance
that such reporting will make users incorrectly think they have a
massive memory leak
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
.
>
> Well, you're right that I tried originally address the issue with
> huge=within_size, but this option makes much more sense for filesystem
> with persistent storage. For ext4, it would be pretty usable option.
Ugh, no, please don't use mount options for file specific behaviours
in filesystems like ext4 and XFS. This is exactly the sort of
behaviour that should either just work automatically (i.e. be
completely controlled by the filesystem) or only be applied to files
specifically configured with persistent hints to reliably allocate
extents in a way that can be easily mapped to huge pages.
e.g. on XFS you will need to apply extent size hints to get large
page sized/aligned extent allocation to occur, and so this
persistent extent size hint should trigger the filesystem to use
large pages if supported, the hint is correctly sized and aligned,
and there are large pages available for allocation.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
.
>
> Well, you're right that I tried originally address the issue with
> huge=within_size, but this option makes much more sense for filesystem
> with persistent storage. For ext4, it would be pretty usable option.
Ugh, no, please don't use mount options for file specific behaviours
in filesystems like ext4 and XFS. This is exactly the sort of
behaviour that should either just work automatically (i.e. be
completely controlled by the filesystem) or only be applied to files
specifically configured with persistent hints to reliably allocate
extents in a way that can be easily mapped to huge pages.
e.g. on XFS you will need to apply extent size hints to get large
page sized/aligned extent allocation to occur, and so this
persistent extent size hint should trigger the filesystem to use
large pages if supported, the hint is correctly sized and aligned,
and there are large pages available for allocation.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
igned char shift;/* 0 1 */
unsigned char offset; /* 1 1 */
/* XXX 2 bytes hole, try to pack */
unsigned int count;/* 4 4 */
.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
/* 0 1 */
unsigned char offset; /* 1 1 */
/* XXX 2 bytes hole, try to pack */
unsigned int count;/* 4 4 */
.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
don't tend to sit idle for 5 hours like this one did
before tripping this.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
don't tend to sit idle for 5 hours like this one did
before tripping this.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
t seen it before, hence it's probably a regression. I
haven't tried to reproduce it yet, so I don't know if it's easy
to trip over.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
t seen it before, hence it's probably a regression. I
haven't tried to reproduce it yet, so I don't know if it's easy
to trip over.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Mon, Oct 17, 2016 at 10:22:56AM +0200, Michal Hocko wrote:
> On Mon 17-10-16 07:49:59, Dave Chinner wrote:
> > On Thu, Oct 13, 2016 at 01:04:56PM +0200, Michal Hocko wrote:
> > > On Thu 13-10-16 09:39:47, Michal Hocko wrote:
> > > > On Thu 13-10-16 11:29:24, Dave C
On Mon, Oct 17, 2016 at 10:22:56AM +0200, Michal Hocko wrote:
> On Mon 17-10-16 07:49:59, Dave Chinner wrote:
> > On Thu, Oct 13, 2016 at 01:04:56PM +0200, Michal Hocko wrote:
> > > On Thu 13-10-16 09:39:47, Michal Hocko wrote:
> > > > On Thu 13-10-16 11:29:24, Dave C
On Thu, Oct 13, 2016 at 01:04:56PM +0200, Michal Hocko wrote:
> On Thu 13-10-16 09:39:47, Michal Hocko wrote:
> > On Thu 13-10-16 11:29:24, Dave Chinner wrote:
> > > On Fri, Oct 07, 2016 at 03:18:14PM +0200, Michal Hocko wrote:
> > [...]
> > > > Unpatched ker
On Thu, Oct 13, 2016 at 01:04:56PM +0200, Michal Hocko wrote:
> On Thu 13-10-16 09:39:47, Michal Hocko wrote:
> > On Thu 13-10-16 11:29:24, Dave Chinner wrote:
> > > On Fri, Oct 07, 2016 at 03:18:14PM +0200, Michal Hocko wrote:
> > [...]
> > > > Unpatched ker
sectors[rw], sec);
> + part_inc_in_flight(>part0, rw);
> + part_stat_unlock();
> +}
Why reimplement generic_start_io_acct() and generic_end_io_acct()?
-Dave.
--
Dave Chinner
da...@fromorbit.com
gt; + *start = jiffies;
> + part_round_stats(cpu, >part0);
> + part_stat_inc(cpu, >part0, ios[rw]);
> + part_stat_add(cpu, >part0, sectors[rw], sec);
> + part_inc_in_flight(>part0, rw);
> + part_stat_unlock();
> +}
Why reimplement generic_start_io_acct() and generic_end_io_acct()?
-Dave.
--
Dave Chinner
da...@fromorbit.com
On Fri, Oct 07, 2016 at 03:18:14PM +0200, Michal Hocko wrote:
> On Thu 06-10-16 13:11:42, Dave Chinner wrote:
> > On Wed, Oct 05, 2016 at 01:38:45PM +0200, Michal Hocko wrote:
> > > On Wed 05-10-16 07:32:02, Dave Chinner wrote:
> > > > On Tue, Oct 04, 2016 at 10:12:
On Fri, Oct 07, 2016 at 03:18:14PM +0200, Michal Hocko wrote:
> On Thu 06-10-16 13:11:42, Dave Chinner wrote:
> > On Wed, Oct 05, 2016 at 01:38:45PM +0200, Michal Hocko wrote:
> > > On Wed 05-10-16 07:32:02, Dave Chinner wrote:
> > > > On Tue, Oct 04, 2016 at 10:12:
On Wed, Oct 12, 2016 at 10:26:34AM +0200, Vitaly Wool wrote:
> On Wed, 12 Oct 2016 09:52:06 +1100
> Dave Chinner <da...@fromorbit.com> wrote:
>
>
> >
> > > +static unsigned long z3fold_shrink_scan(struct shrinker *shrink,
> > > +
On Wed, Oct 12, 2016 at 10:26:34AM +0200, Vitaly Wool wrote:
> On Wed, 12 Oct 2016 09:52:06 +1100
> Dave Chinner wrote:
>
>
> >
> > > +static unsigned long z3fold_shrink_scan(struct shrinker *shrink,
> > > + struct shrink_control *sc)
eflink.c
create mode 100644 fs/xfs/xfs_reflink.h
create mode 100644 fs/xfs/xfs_trans_bmap.c
create mode 100644 fs/xfs/xfs_trans_refcount.c
--
Dave Chinner
da...@fromorbit.com
eflink.c
create mode 100644 fs/xfs/xfs_reflink.h
create mode 100644 fs/xfs/xfs_trans_bmap.c
create mode 100644 fs/xfs/xfs_trans_refcount.c
--
Dave Chinner
da...@fromorbit.com
nt regions - persistent memory device
setup cannot be allowed to change from kernel to kernel. Change in
mapping and device setup like this will cause the corruption of
and/or loss of data in the persistent memory devices that have
changed shape, size or disappeared
Cheers,
Dave.
--
Dave
nt regions - persistent memory device
setup cannot be allowed to change from kernel to kernel. Change in
mapping and device setup like this will cause the corruption of
and/or loss of data in the persistent memory devices that have
changed shape, size or disappeared
Cheers,
Dave.
--
Dave
hrinker = true;
> + }
Just fail creation of the pool. If you can't register a shrinker,
then much bigger problems are about to happen to your system, and
running a new memory consumer that /can't be shrunk/ is not going to
help anyone.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
Just fail creation of the pool. If you can't register a shrinker,
then much bigger problems are about to happen to your system, and
running a new memory consumer that /can't be shrunk/ is not going to
help anyone.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
d and higher compression ratio therefore.
>
> Signed-off-by: Vitaly Wool <vitalyw...@gmail.com>
This seems to implement the shrinker API we removed a ~3 years ago
(commit a0b02131c5fc ("shrinker: Kill old ->shrink API.")). Forward
porting and testing required, perhaps
d and higher compression ratio therefore.
>
> Signed-off-by: Vitaly Wool
This seems to implement the shrinker API we removed a ~3 years ago
(commit a0b02131c5fc ("shrinker: Kill old ->shrink API.")). Forward
porting and testing required, perhaps?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Mon, Oct 10, 2016 at 02:34:34AM -0700, Christoph Hellwig wrote:
> On Mon, Oct 10, 2016 at 05:07:45PM +1100, Dave Chinner wrote:
> > > > *However*, the DAX IO path locking in XFS has changed in 4.9-rc1 to
> > > > match the buffered IO single writer POSIX semantics
On Mon, Oct 10, 2016 at 02:34:34AM -0700, Christoph Hellwig wrote:
> On Mon, Oct 10, 2016 at 05:07:45PM +1100, Dave Chinner wrote:
> > > > *However*, the DAX IO path locking in XFS has changed in 4.9-rc1 to
> > > > match the buffered IO single writer POSIX semantics
of the "dax" namespace and not the "iomap" namespace.
> Rename them to dax_iomap_rw(), dax_iomap_fault() and dax_iomap_actor()
> respectively.
>
> Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com>
> Suggested-by: Dave Chinner <da...@fromorbit.com>
of the "dax" namespace and not the "iomap" namespace.
> Rename them to dax_iomap_rw(), dax_iomap_fault() and dax_iomap_actor()
> respectively.
>
> Signed-off-by: Ross Zwisler
> Suggested-by: Dave Chinner
> Reviewed-by: Christoph Hellwig
> Reviewed-by: Jan
On Sun, Oct 09, 2016 at 08:17:48AM -0700, Christoph Hellwig wrote:
> On Fri, Oct 07, 2016 at 08:47:51AM +1100, Dave Chinner wrote:
> > Except that it's DAX, and in 4.7-rc1 that used shared locking at the
> > XFS level and never took exclusive locks.
> >
> > *Howeve
On Sun, Oct 09, 2016 at 08:17:48AM -0700, Christoph Hellwig wrote:
> On Fri, Oct 07, 2016 at 08:47:51AM +1100, Dave Chinner wrote:
> > Except that it's DAX, and in 4.7-rc1 that used shared locking at the
> > XFS level and never took exclusive locks.
> >
> > *Howeve
On Sun, Oct 09, 2016 at 06:14:57PM +0200, Oleg Nesterov wrote:
> On 10/08, Dave Chinner wrote:
> >
> > On Fri, Oct 07, 2016 at 07:15:18PM +0200, Oleg Nesterov wrote:
> > > > >
> > > > > --- x/fs/xfs/xfs_trans.c
> > > > > +++ x/fs/x
On Sun, Oct 09, 2016 at 06:14:57PM +0200, Oleg Nesterov wrote:
> On 10/08, Dave Chinner wrote:
> >
> > On Fri, Oct 07, 2016 at 07:15:18PM +0200, Oleg Nesterov wrote:
> > > > >
> > > > > --- x/fs/xfs/xfs_trans.c
> > > > > +++ x/fs/x
On Fri, Oct 07, 2016 at 07:15:18PM +0200, Oleg Nesterov wrote:
> On 10/07, Dave Chinner wrote:
> >
> > On Thu, Oct 06, 2016 at 07:17:58PM +0200, Oleg Nesterov wrote:
> > > Probably false positive? Although when I look at the comment above
> > > xfs_sync_sb()
&g
On Fri, Oct 07, 2016 at 07:15:18PM +0200, Oleg Nesterov wrote:
> On 10/07, Dave Chinner wrote:
> >
> > On Thu, Oct 06, 2016 at 07:17:58PM +0200, Oleg Nesterov wrote:
> > > Probably false positive? Although when I look at the comment above
> > > xfs_sync_sb()
&g
er. ISTR this
same issue triggered a long whole discussion about how to move
memory allocation to task based context flags or to push more
context specific information into the shrinkers so they could decide
if the needed to avoid deadlocks or not. That was about 6 months
ago, IIRC, and there's been no followup from the mm side of
things...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
er. ISTR this
same issue triggered a long whole discussion about how to move
memory allocation to task based context flags or to push more
context specific information into the shrinkers so they could decide
if the needed to avoid deadlocks or not. That was about 6 months
ago, IIRC, and there's been no followup from the mm side of
things...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
FS, not change
the implementation to make XFS_TRANS_NO_WRITECOUNT flag to also mean
XFS_TRANS_NOFS.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
FS, not change
the implementation to make XFS_TRANS_NO_WRITECOUNT flag to also mean
XFS_TRANS_NOFS.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
sion test across
multiple kernels.
If you want to stress concurrent access to a single file, please
use direct IO, not DAX or buffered IO.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
sion test across
multiple kernels.
If you want to stress concurrent access to a single file, please
use direct IO, not DAX or buffered IO.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Wed, Oct 05, 2016 at 01:38:45PM +0200, Michal Hocko wrote:
> On Wed 05-10-16 07:32:02, Dave Chinner wrote:
> > On Tue, Oct 04, 2016 at 10:12:15AM +0200, Michal Hocko wrote:
> > > From: Michal Hocko <mho...@suse.com>
> > >
> > > compaction has been d
On Wed, Oct 05, 2016 at 01:38:45PM +0200, Michal Hocko wrote:
> On Wed 05-10-16 07:32:02, Dave Chinner wrote:
> > On Tue, Oct 04, 2016 at 10:12:15AM +0200, Michal Hocko wrote:
> > > From: Michal Hocko
> > >
> > > compaction has been disabled for
y to do this - it was a 20
line change to add XFS_CONFIG_WARN instead of having to audit and
modify ~1800 call sites to do something differently. And because we
know that ASSERT() is not present in all kernels, it isn't ever used
as a replacement for error handling. Perhaps that's the simplest
solution here as well
Just my 2c worth.
-Dave.
--
Dave Chinner
da...@fromorbit.com
to add XFS_CONFIG_WARN instead of having to audit and
modify ~1800 call sites to do something differently. And because we
know that ASSERT() is not present in all kernels, it isn't ever used
as a replacement for error handling. Perhaps that's the simplest
solution here as well
Just my 2c worth.
-Dave.
--
Dave Chinner
da...@fromorbit.com
new transaction
xfs: set up per-AG free space reservations
Dave Chinner (9):
xfs: fix superblock inprogress check
xfs: change mailing list address
xfs: remote attribute blocks aren't really userdata
xfs: quiesce the filesystem after recovery on readonly mount
Merge bra
new transaction
xfs: set up per-AG free space reservations
Dave Chinner (9):
xfs: fix superblock inprogress check
xfs: change mailing list address
xfs: remote attribute blocks aren't really userdata
xfs: quiesce the filesystem after recovery on readonly mount
Merge bra
t error = 0;
> > >
> > > mutex_lock(>bd_fsfreeze_mutex);
> > > if (++bdev->bd_fsfreeze_count > 1) {
> >
> > No limit is put in place so in principle this will eventually turn negative.
>
> Yeah, ok, send a fix...
t error = 0;
> > >
> > > mutex_lock(>bd_fsfreeze_mutex);
> > > if (++bdev->bd_fsfreeze_count > 1) {
> >
> > No limit is put in place so in principle this will eventually turn negative.
>
> Yeah, ok, send a fix...
u'll start to see lots of 65kB allocations being
requested in GFP_NOFS context by the xfs-cil-worker context doing
journal checkpoint formatting
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
see lots of 65kB allocations being
requested in GFP_NOFS context by the xfs-cil-worker context doing
journal checkpoint formatting
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
..
Put your TEST_DIR and SCRATCHMNT mount points outside the xfstests
directory, and this should go away. Most people use /mnt/test and
/mnt/scratch for these
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
..
Put your TEST_DIR and SCRATCHMNT mount points outside the xfstests
directory, and this should go away. Most people use /mnt/test and
/mnt/scratch for these
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Tue, Oct 04, 2016 at 01:43:43PM +0200, Oleg Nesterov wrote:
> On 10/03, Oleg Nesterov wrote:
> >
> > On 10/03, Dave Chinner wrote:
> > >
> > > On Fri, Sep 30, 2016 at 07:14:34PM +0200, Oleg Nesterov wrote:
> > > > On 09/27, Oleg Nes
On Tue, Oct 04, 2016 at 01:43:43PM +0200, Oleg Nesterov wrote:
> On 10/03, Oleg Nesterov wrote:
> >
> > On 10/03, Dave Chinner wrote:
> > >
> > > On Fri, Sep 30, 2016 at 07:14:34PM +0200, Oleg Nesterov wrote:
> > > > On 09/27, Oleg Nes
cessfully with minimal failures and without
crashing the machine. If you're running this group and there's
failures, hangs and crashes all over the place, then you need to
start reporting bugs because that should not be happening on any
kernel
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
cessfully with minimal failures and without
crashing the machine. If you're running this group and there's
failures, hangs and crashes all over the place, then you need to
start reporting bugs because that should not be happening on any
kernel
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
1001 - 1100 of 3916 matches
Mail list logo
