truncate_pagecache_range(VFS_I(ip), ioffset, -1);
Bonus points for working out why the XFS code doesn't just use
PAGE_CACHE_SIZE for rounding here
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
this may be a regression...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
: [0..159]: extent
This error appears in all the golden outputs. If it's correct, then
perhaps it should be filtered out or commented somewhere to explain
why it is expected.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux
On Mon, Jan 20, 2014 at 05:58:55AM -0800, Christoph Hellwig wrote:
On Thu, Jan 16, 2014 at 09:07:21AM +1100, Dave Chinner wrote:
Yes, I think it can be done relatively simply. We'd have to change
the code in xfs_file_aio_write_checks() to check whether EOF zeroing
was required rather than
On Mon, Jan 20, 2014 at 06:17:37PM -0500, Johannes Weiner wrote:
On Fri, Jan 17, 2014 at 11:05:17AM +1100, Dave Chinner wrote:
On Fri, Jan 10, 2014 at 01:10:43PM -0500, Johannes Weiner wrote:
+ /* Only shadow entries in there, keep track of this node */
+ if (!(node-count
writing to deleted files is there but that it's not
getting used.
Not surprising at all - if it's stuck in a writeback loop somewhere,
truncating the file will terminate writeback because it end up being
past EOF and so stops immediately...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Tue, Jan 21, 2014 at 12:50:17AM -0500, Johannes Weiner wrote:
On Tue, Jan 21, 2014 at 02:03:58PM +1100, Dave Chinner wrote:
On Mon, Jan 20, 2014 at 06:17:37PM -0500, Johannes Weiner wrote:
On Fri, Jan 17, 2014 at 11:05:17AM +1100, Dave Chinner wrote:
On Fri, Jan 10, 2014 at 01:10:43PM
.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, Jan 23, 2014 at 06:48:25PM +1100, Dave Chinner wrote:
On Wed, Jan 15, 2014 at 08:24:18PM -0500, Matthew Wilcox wrote:
This series of patches add support for XIP to ext4. Unfortunately,
it turns out to be necessary to rewrite the existing XIP support code
first due to races
large sector size support question, XFS
already supports sector sizes up to 32k in size. The limitation is
actually a limitation of the journal format, so going larger than
that would take some work...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send
multiple pages which is what is needed for
block size page size. fsblock was designed to handle both cases.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
the generic
infrastructure as it stands to handle block/sector sizes larger than
a page size...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
filesystem block.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
if adding
MOUNT_OPTIONS=-o xip adds any problems or not
XIP definitely caused generic/001 to fail, but other than that I
can't really tell. Still, it looks like it functions enough to be
able to add XFS support on top of. I'll get back to you with that ;)
Cheers,
Dave.
--
Dave Chinner
da
On Thu, Jan 23, 2014 at 07:55:50AM -0500, Theodore Ts'o wrote:
On Thu, Jan 23, 2014 at 07:35:58PM +1100, Dave Chinner wrote:
I expect it would be relatively simple to get large blocksizes working
on powerpc with 64k PAGE_SIZE. So before diving in and doing huge
amounts of work
On Thu, Jan 23, 2014 at 04:44:38PM +, Mel Gorman wrote:
On Thu, Jan 23, 2014 at 07:47:53AM -0800, James Bottomley wrote:
On Thu, 2014-01-23 at 19:27 +1100, Dave Chinner wrote:
On Wed, Jan 22, 2014 at 10:13:59AM -0800, James Bottomley wrote:
On Wed, 2014-01-22 at 18:02 +, Chris
complexity in setting up inode lock order instances is required
so that lockdep doesn't confuse the lock ordering semantics of
directories with regular files. As if that code to make lockdep
happy wasn't complex enough already
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Thu, Jan 23, 2014 at 09:51:05PM -0500, Josh Boyer wrote:
On Thu, Jan 23, 2014 at 9:29 PM, Dave Chinner da...@fromorbit.com wrote:
On Thu, Jan 23, 2014 at 08:58:56PM -0500, Josh Boyer wrote:
the existing dependency chain (in reverse order) is:
[ 132.638078]
- #1 ((ip-i_lock)-mr_lock
appreciate it...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
here.
Please cc Dave Chinner on future revisions. He be da man.
The overall intent of the patchset seems reasonable and I agree that it
can't be efficiently done from userspace with the current kernel API.
We *could* do it from userspace by providing facilities for userspace to
query
rates will be more effectively controlled by
restricting CPU time rather than adding extra overhead into the
block layer to account for each individual IO
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
to
the relevant stable kernels.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
workloads most of the referenced inodes in the system are on
the LRU
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
appending i_size updates will only ever see a hole
(zeros), an unwritten region (zeros) or the written data.
Christoph, are you going to get any time to look at doing this in
the next few days?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe
balance under different loads...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
On Sat, Dec 14, 2013 at 03:23:24PM -0500, Tejun Heo wrote:
Hello, Dave.
On Sat, Dec 14, 2013 at 12:53:43PM +1100, Dave Chinner wrote:
That's the fundamental problem here - device removal asks the device
to fsync the filesystem on top of the device that was just removed.
The simple way
support FALLOC_FL_COLLAPSE_RANGE for fallocate
sigh
Rich, we've been here before:
19e73c9 Revert [RESEND, 4/7] xfsprogs: xfsio: add support
FALLOC_FL_COLLAPSE_RANGE
Please go back and read the discussion that lead to that revert.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe
example working set is slightly
larger than what the cache holds. Hence what you are describing is
a cache reclaim threshold effect: something you can avoid with
/proc/sys/vm/vfs_cache_pressure.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line
disagree - given the problem it is resolving leads to silent
filesystem corruption, this patch should be considered somewhat of a
priority to push...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Mon, Dec 16, 2013 at 07:56:04AM -0500, Tejun Heo wrote:
On Mon, Dec 16, 2013 at 07:51:24AM -0500, Tejun Heo wrote:
On Mon, Dec 16, 2013 at 02:56:52PM +1100, Dave Chinner wrote:
What are you suggesting? Implementing separate warm and hot unplug
paths? That makes no sense whatsoever
On Wed, Dec 18, 2013 at 01:01:28AM +0100, Pavel Machek wrote:
On Wed 2013-12-18 10:31:52, Dave Chinner wrote:
On Wed, Dec 18, 2013 at 12:08:43AM +0100, Pavel Machek wrote:
Hi!
Did this patch ever wind up going anywhere? Fedora has it sitting
in
our tree with a comment
need to do is run xfs_repair built from the development
git tree and run it on your filesystem. That will remove the garbage
from the superblocks and make this problem go away forever.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe
filesystem
linux supports. So, ext3 is affected because it's a journalling
filesystem. I didn't list every journalled filesystem Linux
supports - etc means there are more examples that aren't
explicitly listed.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send
On Wed, Dec 18, 2013 at 06:43:43AM -0500, Tejun Heo wrote:
Hello, Dave.
On Wed, Dec 18, 2013 at 11:35:10AM +1100, Dave Chinner wrote:
Perhaps the function invalidate_partition() is badly named. To
state the obvious, fsync != invalidation. What it does is:
1. sync filesystem
the landmine in the code that we've already
stepped on once.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
report uninitialized extents past i_size to be invalid.
Don't think so - I'm running 1.42.9 on my test VM.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
)
And we need to fix all the places that are currently getting the
distinction wrong. SMOP ... ;-) What would help is correct typing of
variables, possibly with sparse support to help us out. Big Job.
Yes, that's what the Christoph's patchset did.
Cheers,
Dave.
--
Dave Chinner
da
vs /mnt/scr/fsx.fsxgood)
XFS gives a good indication that we aren't doing something correctly
w.r.t. mapped XIP writes, as trying to fiemap the file ASSERT fails
with a delayed allocation extent somewhere inside the file after a
sync. I shall keep digging.
Cheers,
Dave.
--
Dave Chinner
da
On Thu, Jan 30, 2014 at 05:42:30PM +1100, Dave Chinner wrote:
On Wed, Jan 15, 2014 at 08:24:18PM -0500, Matthew Wilcox wrote:
This series of patches add support for XIP to ext4. Unfortunately,
it turns out to be necessary to rewrite the existing XIP support code
first due to races
On Thu, Jan 30, 2014 at 08:25:37PM +1100, Dave Chinner wrote:
On Thu, Jan 30, 2014 at 05:42:30PM +1100, Dave Chinner wrote:
On Wed, Jan 15, 2014 at 08:24:18PM -0500, Matthew Wilcox wrote:
This series of patches add support for XIP to ext4. Unfortunately,
it turns out to be necessary
On Thu, Jan 30, 2014 at 10:45:26PM -0700, Ross Zwisler wrote:
On Fri, 31 Jan 2014, Dave Chinner wrote:
The read/write path is broken, Willy. We can't map arbitrary byte
ranges to the DIO subsystem. I'm now certain that the data
corruptions I'm seeing are in sub-sector regions from unaligned
On Tue, Dec 10, 2013 at 08:20:07AM -0500, Josh Boyer wrote:
On Mon, Dec 9, 2013 at 6:55 PM, Dave Chinner da...@fromorbit.com
wrote:
[cc xfs list, cc sta...@vger.kernel.org]
On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote:
On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques
On Tue, Dec 10, 2013 at 08:10:51PM -0500, Josh Boyer wrote:
On Tue, Dec 10, 2013 at 8:03 PM, Dave Chinner da...@fromorbit.com wrote:
Security processes are not something that should be hidden away in
it's own private corner - if there's a problem upstream needs to
take action
On Tue, Dec 10, 2013 at 06:45:54PM -0800, Kees Cook wrote:
On Tue, Dec 10, 2013 at 6:00 PM, Dave Chinner da...@fromorbit.com wrote:
On Tue, Dec 10, 2013 at 08:10:51PM -0500, Josh Boyer wrote:
On Tue, Dec 10, 2013 at 8:03 PM, Dave Chinner da...@fromorbit.com wrote:
Security processes
and complexity to each
filesystem, the cost/benefit analysis comes down so far on the side
of just use __GFP_NOFAIL that doing anything else is sheer lunacy.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
messy. best to avoid it by doing the work at list init
time, IMO.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
On Mon, Dec 09, 2013 at 03:40:23PM -0700, Jens Axboe wrote:
On 12/09/2013 03:39 PM, Dave Chinner wrote:
Hi Jens,
Another day, another blkmq/virtio problem. Running mkfs.ext4 on a
sparse 100TB VM file image, it hangs hard while writing superblock
information:
...
I'll take a look
the cause.
Is the problem reproducable, or is it just a one-off?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
On Fri, Dec 13, 2013 at 09:57:48AM +0800, Ming Lei wrote:
On Tue, Dec 10, 2013 at 6:39 AM, Dave Chinner da...@fromorbit.com wrote:
Hi Jens,
Another day, another blkmq/virtio problem. Running mkfs.ext4 on a
sparse 100TB VM file image, it hangs hard while writing superblock
information
the device delete code is just
plain wrong. That's what needs fixing - removing the cause of
re-entrancy, not the workqueue or writeback code...
Ideas?
Fix the device delete error handling not to re-enter the
filesystem and IO path. It's just wrong.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
there needs to be some special code in there to
handle the we can't write to this device anymore case?
I've been asking for that special code for years, Nigel... :/
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
use the one reservation for the link transaction -
take whichever is larger at calculation time.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Fri, Dec 13, 2013 at 11:22:28AM -0500, Dave Jones wrote:
On Fri, Dec 13, 2013 at 03:16:39AM -0800, Christoph Hellwig wrote:
On Fri, Dec 13, 2013 at 09:48:53PM +1100, Dave Chinner wrote:
All I can say is that there doesn't look to be any obvious signs
that this is a XFS or writeback
testing on
virtio/blk_mq? This is the third regression I've hit since it was
merged, and I'm really not stressing this code nearly as much as
some of the hardware out there is capable of doing
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
best practice to publish CVEs without first
(or ever) directly contacting the relevant upstream developers?
But, regardless of how broken I think the CVE process is, commit
071c529 (xfs: underflow bug in xfs_attrlist_by_handle()) should be
picked up by the stable kernels.
Cheers,
Dave.
--
Dave
);
}
i.e. adding shrink_control interfaces to the list_lru code only
requires the addition of two simple functions, not a major
API and implementation rework
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
...
Signed-off-by: Vladimir Davydov vdavy...@parallels.com
Cc: Glauber Costa glom...@openvz.org
Cc: Dave Chinner dchin...@redhat.com
Cc: Al Viro v...@zeniv.linux.org.uk
---
fs/super.c |8 +++-
fs/xfs/xfs_super.c |6 +++---
include/linux/fs.h |6 --
3 files changed
,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
in the list_lru structure can already work as memcg-aware.
Let us mark them so.
Signed-off-by: Vladimir Davydov vdavy...@parallels.com
Cc: Glauber Costa glom...@openvz.org
Cc: Dave Chinner dchin...@redhat.com
Cc: Al Viro v...@zeniv.linux.org.uk
---
fs/gfs2/quota.c |2 +-
fs/super.c |2
is
the one that matters the most.
This should be at the start of the series.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
...@parallels.com
Cc: Glauber Costa glom...@openvz.org
Cc: Dave Chinner dchin...@redhat.com
Cc: Johannes Weiner han...@cmpxchg.org
Cc: Michal Hocko mho...@suse.cz
Cc: Andrew Morton a...@linux-foundation.org
Cc: Al Viro v...@zeniv.linux.org.uk
Cc: Balbir Singh bsinghar...@gmail.com
Cc: KAMEZAWA Hiroyuki
coverage in xfstests so
we can validate that it works the way it is supposed to and that we
don't break it in future, and that all filesystems behave the same
way
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
ping?
On Wed, Apr 09, 2014 at 07:20:09PM +1000, Dave Chinner wrote:
On Wed, Mar 26, 2014 at 08:11:13PM +0100, Andres Freund wrote:
Hi,
At LSF/MM there was a slot about postgres' problems with the kernel. Our
top#1 concern is frequent slow read()s that happen while another process
On Mon, Apr 28, 2014 at 10:54:52AM +0530, Aneesh Kumar K.V wrote:
Dave Chinner da...@fromorbit.com writes:
On Sun, Apr 27, 2014 at 09:44:31PM +0530, Aneesh Kumar K.V wrote:
Hi
As per LSF/MM summit discussion I am reposting the richacl patchset for
upstream inclusion. The patchset
of the other calls of may_create.
IMO, the third argument should be MAY_CREATE_FILE or MAY_CREATE_DIR,
which is what the boolean evaluates to in may_create()
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
, not a bunch of booleans that
are simply evaluated into flags...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
() would be useful. I can see people getting
this wrong in future.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
a simple uid match? Some comments
explaining this for people unfamiliar with richacls would be nice.
Not to mention the commit message should also explain the change...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
the commented out types?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
is in use.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
perhaps dentries also
need a well defined being torn down and freed state where new
references cannot be taken even though the dentry can still be
found...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Hellwig (4):
direct-io: add flag to allow aio writes beyond i_size
xfs: always use unwritten extents for direct I/O writes
xfs: allow appending aio writes
xfs: ensure correct timestamp updates from truncate
Dan Carpenter (1):
xfs: extra semi-colon breaks a condition
Dave
On Mon, Mar 31, 2014 at 11:53:31PM +0900, Namjae Jeon wrote:
From: Namjae Jeon namjae.j...@samsung.com
FALLOC_FL_INSERT_RANGE was mentioned as the opposite command of collapse
range from discussion between Hugh Dickins and Dave Chinner.
In continuation of the work of making the process
On Wed, Mar 19, 2014 at 02:57:06PM +0100, Miklos Szeredi wrote:
Hi Dave,
On Mon, Feb 17, 2014 at 07:19:11PM +1100, Dave Chinner wrote:
On Wed, Feb 12, 2014 at 06:18:52PM +0100, Miklos Szeredi wrote:
On Tue, Feb 11, 2014 at 05:01:41PM +0100, Miklos Szeredi wrote:
On Mon, Feb 10, 2014
techniques.
I haven't seen anything else that uses similar techniques to the XFS
code - I wrote it back in 2005 before there was generic per-cpu
counter infrastructure, and I've been keeping an eye out as
to whether it could be replaced with generic code ever since
Cheers,
Dave.
--
Dave Chinner
da
,
and they are in the subsystem trees, that's a fine time to push to get
the changes into xfstests.
I asked whether this patchset is going to make 3.15 and reviewed the
xfstests patches that had been posted earlier today. About 12 hours
before I read this thread ;)
Cheers,
Dave.
--
Dave Chinner
da
large databases to
be hosted on
I've tried a few tweaks to the test program, but I haven't been able
to make it misbehave. What do I need to tweak in the test program or
my test VM to make the kernel misbehave like you reported?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
to do this if you are seeing ongoing
problems. Often just freeing up space in the filesystem will fix the
problem...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
On Wed, Apr 23, 2014 at 12:40:58PM +1000, NeilBrown wrote:
This is a somewhat shorter patchset for loop-back NFS support than
last time, thanks to the excellent feedback and particularly to Dave
Chinner. Thanks.
Avoiding the wait-for-congestion which can trigger a livelock is much
the same
;
There was nothing wrong with that code. I suspect coccinelle bustage.
Agreed, especially given that the variable is declared as:
bool ordered = false;
So it can only have the values of false and true
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send
like file fragmentation. Non-fragmented 50GB files
should be removed in a few milliseconds. but if you've badly
fragmented the files, there could be 10 million extents in a 50GB
file. A few milliseconds per extent removal gives you
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
, you probably removed the only
significantly large files in the filesystem
So, the files your removed are now free space, so free space
fragmentation is what we need to look at. i.e. use the freesp
command to dump the histogram and summary of the free space...
Cheers,
Dave.
--
Dave Chinner
the excessive CPU
load.
I haven't changed anything in userspace for the past couple of
months, the only thing that has changed is the kernel. I haven't
looked at this any further and have no idea what to do to debug it
further, so let me know if you need more information
Cheers,
Dave.
--
Dave
On Tue, Apr 15, 2014 at 05:53:36PM +1000, Dave Chinner wrote:
Hi Peter,
I'm guessing that x86 vdso problems are in your area of expertise,
if not can you point me at the right person to bug?
And you can ignore it. The VM wasn't running the kernel I thought it
was - it was an old kernel from
(current-flags PF_FSTRANS))
- goto redirty;
We still need to ensure this rule isn't broken. If it is, the
filesystem will silently deadlock in delayed allocation rather than
gracefully handle the problem with a warning
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
off all reclaim of filesystem objects mechanism
all around the kernel doesn't sit well with me...
And, again, PF_FSTRANS looks plainly wrong in this code - it sure
isn't a fs transaction context we are worried about here...
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list
, then we need to fix them individually
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
(xfs_log_item_desc_zone, KM_SLEEP | KM_NOFS);
KM_NOFS needs to work, otherwise XFS is just a huge steaming pile of
memory reclaim deadlocks regardless of whether you are using
loopback NFS or not.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux
for
XFS - we managed to get rid of most of the false positives like this
by ensuring that only the ilock is taken within memory reclaim and
memory reclaim can't be entered while we hold the ilock.
You can't do that with the i_mutex, though
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Wed, Apr 16, 2014 at 04:22:01PM +1000, NeilBrown wrote:
On Wed, 16 Apr 2014 15:49:42 +1000 Dave Chinner da...@fromorbit.com wrote:
On Wed, Apr 16, 2014 at 02:03:36PM +1000, NeilBrown wrote:
lockdep reports a locking chain
sk_lock-AF_INET -- rtnl_mutex -- pcpu_alloc_mutex
On Wed, Apr 16, 2014 at 04:04:59PM +1000, Dave Chinner wrote:
On Wed, Apr 16, 2014 at 02:03:36PM +1000, NeilBrown wrote:
xfs_file_*_read holds an inode lock while calling a generic 'read'
function. These functions perform read-ahead and are quite likely to
allocate memory.
Yes, that's
On Wed, Apr 16, 2014 at 04:49:41PM +1000, NeilBrown wrote:
On Wed, 16 Apr 2014 16:25:20 +1000 Dave Chinner da...@fromorbit.com wrote:
On Wed, Apr 16, 2014 at 02:03:37PM +1000, NeilBrown wrote:
__d_alloc can be called with i_mutex held, so it is safer to
use GFP_NOFS.
lockdep
. Do the same for all the other memory reclaim
operations in the NFS client, and you've got a solution that should
work without needing to walk all over the rest of the kernel
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux
On Thu, Apr 17, 2014 at 11:50:18AM +1000, NeilBrown wrote:
On Thu, 17 Apr 2014 11:27:39 +1000 Dave Chinner da...@fromorbit.com wrote:
On Thu, Apr 17, 2014 at 10:20:48AM +1000, NeilBrown wrote:
A good example is the deadlock with the flush-* threads.
flush-* will lock a page
On Thu, Apr 17, 2014 at 11:03:50AM +1000, NeilBrown wrote:
On Wed, 16 Apr 2014 16:17:26 +1000 NeilBrown ne...@suse.de wrote:
On Wed, 16 Apr 2014 15:37:56 +1000 Dave Chinner da...@fromorbit.com wrote:
On Wed, Apr 16, 2014 at 02:03:36PM +1000, NeilBrown wrote
On Thu, Apr 17, 2014 at 10:51:05AM +1000, NeilBrown wrote:
On Wed, 16 Apr 2014 19:00:51 +1000 Dave Chinner da...@fromorbit.com wrote:
On Wed, Apr 16, 2014 at 04:49:41PM +1000, NeilBrown wrote:
On Wed, 16 Apr 2014 16:25:20 +1000 Dave Chinner da...@fromorbit.com
wrote:
On Wed
- add missing O_TMPFILE inode security context initialisation
Brian Foster (1):
xfs: fix tmpfile/selinux deadlock and initialize security
Dave Chinner (8):
xfs: kill buffers over failed write ranges properly
xfs: write
at that deep leaf function...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
601 - 700 of 3915 matches
Mail list logo
