On Wed, Jul 31, 2013 at 05:15:42PM +0200, Jan Kara wrote:
> On Wed 31-07-13 14:15:46, Dave Chinner wrote:
> > From: Dave Chinner
> >
> > Inodes are removed lazily from the bdi writeback list, so in the
> > absence of sync(2) work inodes will build up on the bdi writbac
On Wed, Jul 31, 2013 at 08:48:40AM +0200, Sedat Dilek wrote:
> On Wed, Jul 31, 2013 at 6:15 AM, Dave Chinner wrote:
> > Hi folks,
> >
> > This series of patches is against the curent mmotm tree here:
> >
> > http://git.cmpxchg.org/cgit/linux-mmotm.git/
> &g
don't care for how it's named, located or used - I just want to be
able to use the infrastructure it provides. As such renaming and
relocating it is not something I'm about to do in this specific
patchset
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this l
On Thu, Aug 01, 2013 at 01:12:35AM -0700, Christoph Hellwig wrote:
> On Wed, Jul 31, 2013 at 02:15:41PM +1000, Dave Chinner wrote:
> > From: Dave Chinner
> >
> > Some filesystems don't use the VFS inode hash and fake the fact they
> > are hashed so that all th
On Thu, Aug 01, 2013 at 02:07:39PM +0900, Namjae Jeon wrote:
> 2013/8/1, Dave Chinner :
> > On Wed, Jul 31, 2013 at 11:42:00PM +0900, Namjae Jeon wrote:
> >> From: Namjae Jeon
> >>
> >> Fallocate now supports new FALLOC_FL_COLLAPSE_RANGE flag.
> >> The
http://oss.sgi.com/archives/xfs/2012-12/msg00124.html
Yeah, probably makes sense to do this. I'll have a look at porting
it forwards to my current tree as xfs_vnodeops.c has gone away in
that series...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list:
On Thu, Aug 01, 2013 at 02:33:09PM +0900, Namjae Jeon wrote:
> 2013/8/1, Dave Chinner :
> > On Wed, Jul 31, 2013 at 11:42:14PM +0900, Namjae Jeon wrote:
> >> From: Namjae Jeon
> >>
> >> New fallocate flag FALLOC_FL_COLLAPSE_RANGE implementation for XFS.
s functionality in
robust manner to the VFS
And, like all compression formats in the kernel, they last about 3
months before someone comes up with some fancy new one that is 1%
faster or smaller at something, and we end up with a proliferation
of different supported compression formats. What
writepages call will update the timestamp.
Oh, I missed that - I thought you were setting AS_CMTIME during
.page_mkwrite.
Setting it in clear_page_dirty_for_io() is too late for filesystems
to include it in their existing transactions during .writepage, (at
least for XFs and ext4) because they do
On Tue, Aug 20, 2013 at 02:54:01PM -0700, Andy Lutomirski wrote:
> On Tue, Aug 20, 2013 at 2:48 PM, Dave Chinner wrote:
> > On Tue, Aug 20, 2013 at 09:42:34AM -0700, Andy Lutomirski wrote:
> >> On Tue, Aug 20, 2013 at 9:00 AM, Jan Kara wrote:
> >> > On Mon 19-0
On Tue, Aug 20, 2013 at 05:47:10PM -0700, Andy Lutomirski wrote:
> On Tue, Aug 20, 2013 at 3:43 PM, Dave Chinner wrote:
> > On Tue, Aug 20, 2013 at 02:54:01PM -0700, Andy Lutomirski wrote:
> >> On Tue, Aug 20, 2013 at 2:48 PM, Dave Chinner wrote:
> >> > On Tue, Au
On Thu, Jul 18, 2013 at 05:21:17PM -0500, Ben Myers wrote:
> Dave,
>
> On Thu, Jul 18, 2013 at 04:16:32PM -0500, Ben Myers wrote:
> > On Thu, Jul 18, 2013 at 01:42:03PM +1000, Dave Chinner wrote:
> > > On Wed, Jul 17, 2013 at 05:17:36PM -0700, Linus Torvalds wrote:
> &g
. Other
filesystems will be more efficient, but because they have more
scalable/complex orphan inode handling it's going to take longer to
implement O_TMPFILE support for them
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscr
ds?
I'll stop there. This is fundamentally broken. It's an attempt to do
a multi-page write operation without any of the supporting
structures needed to handle the failure cases properly. The nested
page locking has "deadlock" written all over it, and the lack of
partial
On Tue, Jul 23, 2013 at 02:58:58PM -0700, Jeremy Allison wrote:
> On Tue, Jul 23, 2013 at 05:10:27PM +1000, Dave Chinner wrote:
> > So, we are nesting up to 32 page locks here. That's bad. And we are
> > nesting kmap() calls for all the pages individually - is that even
> &g
On Mon, Jul 22, 2013 at 05:06:01AM +0100, Al Viro wrote:
> On Mon, Jul 22, 2013 at 11:25:17AM +1000, Dave Chinner wrote:
>
> > I'll just point out that it can make the whole thing worse, too.
> > For example, for ext3/4, the tmpfile being created has to be added
> > t
-[ cut here ]
I just reproduced this by chance. I know exactly what I was doing
when it went bang, so I might be able to reduce it from scattergun
blast testing to be able to reproduce it on demand.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list
- is probably doing the wrong this. i.e. that it assumes that a
clean buffer item is only referenced in this transaction and so it
can unconditionally free it. That's an invalid assumption, and
exactly the situation that the above assert was designed to catch.
Can you try the patch below? It s
y_safe(item, next, &trans->r_itemq, ri_list) {
case XLOG_RECOVER_PASS2:
if (ra_qdepth++ >= MAX_QDEPTH) {
recover_items(log, trans, &buffer_list,
&ra_item_list);
ra_qdept
On Thu, Jul 25, 2013 at 09:17:01AM +0100, Steven Whitehouse wrote:
> Hi,
>
> On Wed, 2013-07-24 at 12:47 +1000, Dave Chinner wrote:
> > On Tue, Jul 23, 2013 at 02:58:58PM -0700, Jeremy Allison wrote:
> > > Having said that the OEMs that are using it does
> > > f
On Fri, Jul 26, 2013 at 02:36:15PM +0800, Zhi Yong Wu wrote:
> Dave,
>
> All comments are good to me, and will be applied to next version, thanks a
> lot.
>
> On Fri, Jul 26, 2013 at 10:50 AM, Dave Chinner wrote:
> > On Thu, Jul 25, 2013 at 04:23:39PM +0800, zw
take an event trace with trace-cmd and attach the output of
the report?
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.k
On Thu, Jul 25, 2013 at 12:50:53PM -0500, Dave Kleikamp wrote:
> Signed-off-by: Dave Kleikamp
> Cc: Ben Myers
> Cc: Alex Elder
> Cc: x...@oss.sgi.com
Looks fine.
Acked-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "
do not need to be there, and the
"out:" label moved to above the call to xlog_recover_free_trans() so
the main loop does the right thing when an error occurs.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-k
On Wed, Aug 14, 2013 at 01:59:02PM +0800, Zhi Yong Wu wrote:
> On Wed, Aug 14, 2013 at 1:35 PM, Dave Chinner wrote:
> > On Wed, Jul 31, 2013 at 04:42:45PM +0800, zwu.ker...@gmail.com wrote:
> >> From: Zhi Yong Wu
> >>
> >> It can take a long time to run
don't care to look any further because the
problem is of your own making. In future, please check first that
the bug you are reporting is reproducable on a current upstream
kernel and userspace.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the
On Sat, May 11, 2013 at 04:09:40PM +0400, Dmitry Monakhov wrote:
> On Tue, 7 May 2013 09:37:07 -0400, Dave Jones wrote:
> > started compiling a kernel, and then...
> >
> I've bisected this one.
> commit 666d644cd72a9ec58b353209ff191d7430f3b357
> Author: Dave Chinner
On Fri, May 10, 2013 at 02:47:35PM +0900, OGAWA Hirofumi wrote:
> Dave Chinner writes:
>
> >> tux3:
> >> Operation CountAvgLatMaxLat
> >>
> >> NTCreateX1477980 0.00312.
7;t the easiest "support all filesystems" hack just be to add
a destination offset parameter to do_splice_direct() and call that
when the filesystem doesn't supply a ->copy_range method? i.e. use
the mechanisms we already have for copying from one file to another
via the p
On Tue, May 14, 2013 at 03:04:40PM -0700, Zach Brown wrote:
> On Wed, May 15, 2013 at 07:42:51AM +1000, Dave Chinner wrote:
> > On Tue, May 14, 2013 at 02:15:22PM -0700, Zach Brown wrote:
> > > I'm going to keep hacking away at this. My next step is to get ext4
>
On Tue, May 14, 2013 at 06:37:19PM +0200, Lukas Czerner wrote:
> ->invalidatepage() aop now accepts range to invalidate so we can make
> use of it in xfs_vm_invalidatepage()
>
> Signed-off-by: Lukas Czerner
> Reviewed-by: Ben Myers
> Cc: x...@oss.sgi.com
Acked-by: Da
.
Just what is the shrinker infrastructure supposed to do with a
random error code?
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 m
two hardware RAID
> devices does not deliver any improved performance for
> single-threaded writes. (Have not thoroughly tested this
> configuration fully with multiple writers, though.)
Of course not - you are CPU bound and nothing you do to the storage
will change that.
Cheers,
D
i.e. each specific negative return value needs to have the potential
for defining a different behaviour.
So if any change needs to be made, it is to change the -1 return
value to an enum and have the shrinkers return that enum when they
want an abort.
-Dave.
--
Dave Chinner
dchin...@redhat.com
-
s /dev/loop0*
>
> Note the /dev/loop0p1 node. Run losetup -d /dev/loop0 and see if it is
> still there.
Jens, can we get one of these fixes merged quickly? xfstests is
unusable on any kernel more recent than 3.9-rc4 because of these
problems
Cheers,
Dave.
--
Dave Chinner
da...@fromor
On Tue, Apr 09, 2013 at 09:01:39AM +0200, Jens Axboe wrote:
> On Tue, Apr 09 2013, Dave Chinner wrote:
> > On Thu, Apr 04, 2013 at 04:30:54PM -0400, Phillip Susi wrote:
> > > > I have not tested it yet, but I am pretty sure it won't work. It
> > > > looks lik
cts and the memory
> that is freed when slab objects are reclaimed that has to be taken into
> account.
Node awareness within the shrinker infrastructure and LRUs make the
relationship much more direct ;)
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: se
ny real
> deadlock potential?
It sure will. We've been reporting that vm_map_ram is doing
GFP_KERNEL allocations from GFP_NOFS context for years, and have
reported plenty of lockdep dumps as a result of it.
But that's not the problem that is occurring above - lockstat is
probably a good thing
re you'll disclose such information with your
results, otherwise nobody is ever going to trust anything you say
about tux3
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/
d by commit 3fe58f30b4fc ("xfs: add CRC checks for quota
> blocks").
>
> I have used the xfs tree from next-20130426 for today.
CONFIG_XFS_QUOTA=y will fix it.
Or, alternatively, apply this patch:
http://oss.sgi.com/pipermail/xfs/2013-April/025434.html
Cheers,
Dave.
--
Da
ads that contain metadata with a flag, so that the
> flusher thread can write them back at the same priority as reads.
Ext4 is already using REQ_META for this purpose.
I'm surprised that no-one has suggested "change the IO elevator"
yet.
Cheers,
Dave.
--
Dave Chinner
da...@
On Fri, Apr 12, 2013 at 11:19:52AM -0400, Theodore Ts'o wrote:
> On Fri, Apr 12, 2013 at 02:50:42PM +1000, Dave Chinner wrote:
> > > If that is the case, one possible solution that comes to mind would be
> > > to mark buffer_heads that contain metadata with a flag, so tha
On Thu, May 16, 2013 at 11:35:08AM -0400, David Oostdyk wrote:
> On 05/16/13 07:36, Stan Hoeppner wrote:
> >On 5/15/2013 7:59 PM, Dave Chinner wrote:
> >>[cc xfs list, seeing as that's where all the people who use XFS in
> >>these sorts of configurations hang out.
On Thu, May 16, 2013 at 02:27:52PM +0200, Oskar Andero wrote:
> On 13:52 Thu 16 May , Dave Chinner wrote:
> > On Thu, May 16, 2013 at 10:42:16AM +0200, Oskar Andero wrote:
> > > The shrinkers must return -1 to indicate that it is busy. Instead, treat
> > >
On Mon, May 20, 2013 at 11:14:27AM +0200, Oskar Andero wrote:
> Add a BUG_ON to catch any illegal value from the shrinkers. This fixes a
> potential bug if scan_objects returns a negative other than -1, which
> would lead to undefined behaviour.
>
> Cc: Glauber Costa
> Cc:
thread is not doing the
writeback work fast enough when memory is low - can you comment on
this at all, Mel?
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.or
to strip SUID/SGID during the truncate operation?
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-in
On Tue, May 21, 2013 at 07:40:16PM -0400, Dave Jones wrote:
> On Wed, May 22, 2013 at 09:34:29AM +1000, Dave Chinner wrote:
> > On Tue, May 21, 2013 at 06:52:57PM -0400, Dave Jones wrote:
> > > [ 464.210598] XFS: Assertion failed: (mask &
> (ATTR_MODE|ATT
On Tue, May 21, 2013 at 08:08:03PM -0400, Dave Jones wrote:
> On Wed, May 22, 2013 at 09:54:10AM +1000, Dave Chinner wrote:
> > On Tue, May 21, 2013 at 07:40:16PM -0400, Dave Jones wrote:
> > > On Wed, May 22, 2013 at 09:34:29AM +1000, Dave Chinner wrote:
> > > >
On Tue, May 21, 2013 at 10:56:05PM -0400, Dave Jones wrote:
> On Wed, May 22, 2013 at 10:16:03AM +1000, Dave Chinner wrote:
>
> Seems like I can trigger this from paths other than truncate too.. (eg,
> sys_open)
O_TRUNC?
> The mask is always 0xa068 though if that helps.
A bi
On Wed, May 22, 2013 at 12:15:21AM -0400, Dave Jones wrote:
> On Wed, May 22, 2013 at 02:03:18PM +1000, Dave Chinner wrote:
>
> > That doesn't make a whole lot of sense to me. What am I missing?
> > Are you seeing this fire at all from notify_change()?
>
On Wed, May 22, 2013 at 01:29:38AM -0400, Dave Jones wrote:
> On Wed, May 22, 2013 at 03:12:43PM +1000, Dave Chinner wrote:
>
> > > [ 36.339105] XFS (sda2): xfs_setattr_size: mask 0xa068 mismatch on
> file 0\xffb8\xffd3-\xff88\x\x
> >
k overflow.
> 15320.364308¨ CPU: 0 Tainted: GF W3.9.2 #1
> 15320.364309¨ Process rhts-test-runne (pid: 625, task: 3dccc890, ksp:
> 0
and there you go - a stack overflow. Your kernel stack size is
too small.
I'd suggest that you need 16k stacks on s390 - II
On Wed, May 22, 2013 at 03:51:47PM +1000, Dave Chinner wrote:
> On Wed, May 22, 2013 at 01:29:38AM -0400, Dave Jones wrote:
> > On Wed, May 22, 2013 at 03:12:43PM +1000, Dave Chinner wrote:
> >
> > > > [ 36.339105] XFS (sda2): xfs_setattr_size: mask 0xa068 mismat
On Wed, May 22, 2013 at 12:19:46PM -0400, Dave Jones wrote:
> On Wed, May 22, 2013 at 10:22:52AM -0400, Dave Jones wrote:
> > On Wed, May 22, 2013 at 03:51:47PM +1000, Dave Chinner wrote:
> >
> > > > Tomorrow I'll also try running some older kernels with the
On Wed, May 22, 2013 at 11:16:56PM -0400, CAI Qian wrote:
> - Original Message -
> > From: "Dave Chinner"
> > To: "CAI Qian"
> > Cc: "LKML" , sta...@vger.kernel.org,
> > x...@oss.sgi.com
> > Sent: Wednesday, May 22, 2
er benchmarks)
we can't really determine if this is a good solution or not...
IOWs, you need more than one microbenchmark that interacts with
some naive monitoring code to justify the complexity these locking
changes introduce
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.c
On Thu, May 23, 2013 at 02:49:48PM -0400, Dave Jones wrote:
> On Thu, May 23, 2013 at 07:54:54AM +1000, Dave Chinner wrote:
>
> > Gah, I've got not idea what the hell I was smoking yesterday
> > afternoon. 0x2000 is actually ATTR_FILE, and 0x8000 is ATTR_OPEN.
> >
On Thu, May 23, 2013 at 08:49:06PM -0400, Dave Jones wrote:
> On Fri, May 24, 2013 at 08:30:38AM +1000, Dave Chinner wrote:
>
> > > > Which I put just before the assert that is firing on your machine.
> > > >
> > > > And, obviously, it isn&#
On Thu, May 23, 2013 at 11:03:00PM -0400, Dave Jones wrote:
> On Thu, May 23, 2013 at 09:52:19PM -0400, Dave Jones wrote:
> > On Fri, May 24, 2013 at 11:26:25AM +1000, Dave Chinner wrote:
> >
> > > You want to print the debug output if the masked value !=
On Thu, May 23, 2013 at 05:34:23PM -0400, Waiman Long wrote:
> On 05/23/2013 05:42 AM, Dave Chinner wrote:
> >On Wed, May 22, 2013 at 09:37:25PM -0400, Waiman Long wrote:
> >>Change log:
> >>
> >>v2->v3
> >> - Fix the RCU lock problem found by Al V
on error
If you haven't already repaired the filesystem, can you send me a
metadump of the filesystem in question?
> [ 40.642521] BUG: soft lockup - CPU#0 stuck for 22s! [fsck.ext2:294]
I'm not sure what this has to do with the XFS problem - it's
apparently stuck in invalidat
On Tue, May 28, 2013 at 05:15:44PM -0400, Dave Jones wrote:
> On Wed, May 29, 2013 at 07:10:12AM +1000, Dave Chinner wrote:
> > On Tue, May 28, 2013 at 12:12:30PM -0400, Dave Jones wrote:
> > > box crashed, and needed rebooting. On next bootup, when it found the
> dirty
On Tue, May 28, 2013 at 05:41:37PM -0400, Dave Jones wrote:
> On Wed, May 29, 2013 at 07:32:48AM +1000, Dave Chinner wrote:
> > On Tue, May 28, 2013 at 05:15:44PM -0400, Dave Jones wrote:
> > > On Wed, May 29, 2013 at 07:10:12AM +1000, Dave Chinner wrote:
> > > >
since 3.9-rc4:
$ glo v3.9-rc4..HEAD -- drivers/block/loop.c
c1681bf loop: prevent bdev freeing while device in use
8761a3d loop: cleanup partitions when detaching loop device
183cfb5 loop: fix error return code in loop_add()
$
So this looks like someone hasn't been testing their loopback
dri
ly to have implicit dependencies on the barrier
effect of metadata operations on data IO...
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 in
On Fri, Mar 08, 2013 at 05:20:34PM -0800, Michel Lespinasse wrote:
> On Fri, Mar 8, 2013 at 4:32 PM, Dave Chinner wrote:
> > On Wed, Mar 06, 2013 at 03:21:50PM -0800, Michel Lespinasse wrote:
> >> When the first queued waiter is a reader, wake all readers instead of
> >
On Sun, Mar 10, 2013 at 10:17:42PM -0700, Michel Lespinasse wrote:
> On Sun, Mar 10, 2013 at 5:16 PM, Dave Chinner wrote:
> > On Fri, Mar 08, 2013 at 05:20:34PM -0800, Michel Lespinasse wrote:
> >> On Fri, Mar 8, 2013 at 4:32 PM, Dave Chinner wrote:
> >> > Isn&
y(mapping_hwpoison(inode->i_mapping) && !newsize))
> + mapping_clear_hwpoison(inode->i_mapping);
So only a truncate to zero size will clear the poison flag?
What happens if it is the last page in the mapping that is poisoned,
and we truncate that away? Shouldn't tha
On Thu, Aug 23, 2012 at 10:39:32PM -0400, Naoya Horiguchi wrote:
> On Fri, Aug 24, 2012 at 11:31:18AM +1000, Dave Chinner wrote:
> > On Wed, Aug 22, 2012 at 11:17:35AM -0400, Naoya Horiguchi wrote:
> > > "HWPOISON: report sticky EIO for poisoned file" still has a cor
On Fri, Aug 24, 2012 at 01:24:16PM -0400, Naoya Horiguchi wrote:
> On Fri, Aug 24, 2012 at 02:39:17PM +1000, Dave Chinner wrote:
> > On Thu, Aug 23, 2012 at 10:39:32PM -0400, Naoya Horiguchi wrote:
> > > On Fri, Aug 24, 2012 at 11:31:18AM +1000, Dave Chinner wrote:
> > >
ing all of this? I'm not sure that so
many new files are needed - putting it all in fs/hot_tracking.[ch]
might make more sense, or if all 8 fs/hot* files remain, putting
them in their own subdirectory might be an idea (like quota).
I'll comment on the code when I get a bit of time to
On Tue, Sep 18, 2012 at 10:24:55AM +0800, Zhi Yong Wu wrote:
> On Tue, Sep 18, 2012 at 5:30 AM, Dave Chinner wrote:
> > On Mon, Sep 17, 2012 at 03:18:34PM +0800, zwu.ker...@gmail.com wrote:
> >> 20 files changed, 2275 insertions(+), 1 deletions(-)
> >> create m
be effectively undefined - what happens to
latencies if you generate memory pressure while the test is running?
FWIW, if you are going to change generic code, you need to present
results for other filesystems as well (xfs, btrfs are typical), as
they may not have the same problems as ext4 or react
.
>
> Here lies my major concern about dirty_background_time: the write
> bandwidth estimation is an _estimation_ and will sure become wildly
> wrong in some cases. So the dirty_background_time implementation based
> on it will not always work to the user expectations.
>
> One im
d data quickly"
Besides, seek-hole/data is still shiny new and lots of developers
aren't even aware of it's presence in recent kernels. Removing new
functionality saying "no-one is using it" is like smashing the egg
before the chicken hatches (or is it cutting of the chicke
need to limit xfstests to the aio group here. If the loop
device is what you are actually testing, then you probably want to
run the auto/quick groups as they will do a whole lot more than just
data IO to the loop devices...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe
On Mon, Jan 21, 2013 at 08:08:53PM +0400, Glauber Costa wrote:
> On 11/28/2012 03:14 AM, Dave Chinner wrote:
> > [PATCH 09/19] list_lru: per-node list infrastructure
> >
> > This makes the generic LRU list much more scalable by changing it to
> > a {list,lock,count} t
On Wed, Jan 23, 2013 at 06:36:33PM +0400, Glauber Costa wrote:
> On 01/22/2013 03:21 AM, Dave Chinner wrote:
> > On Mon, Jan 21, 2013 at 08:08:53PM +0400, Glauber Costa wrote:
> >> On 11/28/2012 03:14 AM, Dave Chinner wrote:
> >>> [PATCH 09/19] list_lru
ons, please let me
> > > know.
> > >
> > > --
> > >
> > > From: Dave Chinner
> > >
> > > commit eb178619f930fa2ba2348de332a1ff1c66a31424 upstream.
> > >
> > > When _xfs_buf_find is passed an out of range add
On Wed, Feb 13, 2013 at 10:13:16AM -0800, Eric W. Biederman wrote:
> Joel Becker writes:
>
> > On Wed, Nov 21, 2012 at 10:55:24AM +1100, Dave Chinner wrote:
> >> > diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
> >> > index 2778258..3656b88 10
gt; > > I have that rule in place for some other subsystems that don't want me
> > > applying stuff that they aren't aware of, and have no problem doing the
> > > same
> > > thing here.
> > >
> > > Just let me know.
Sounds like a fine
e332a1ff1c66a31424 upstream.
>
> It has been reported to cause problems:
> http://bugzilla.redhat.com/show_bug.cgi?id=909602
>
> Acked-by: Ben Myers
> Cc: Dave Chinner
> Cc: Brian Foster
> Cc: CAI Qian
> Cc: Paolo Bonzini
> Signed-off-by: Greg Kroah-Hartma
sync_file+0x208/0x2d0
And postgres gets stuck there too. So what you are seeing is likely
an ext4 problem, not an IO scheduler problem.
Suggestion: try the same test with XFS. If the problem still exists,
then it *might* be an ioscheduler problem. If it goes away, then
it's an ext4 problem.
Che
__u32 num_writes;
> + __u32 temperature;
> + __u8 live;
> + char filename[PATH_MAX];
Don't put the filename in the ioctl and open the file in the kernel.
Have userspace open the file directly and issue the ioctl on the fd
that is returned.
Cheers,
Dave.
--
e do not want random users to be able to
infer what files users are accessing from this information.
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 majo
gt; + }
> +
> + len = hot_debugfs_copy(data, data->log_work_buff, len);
> + spin_unlock(&data->log_lock);
> +
> + return len;
> +}
Aren't you just recreating seq_printf() here? i.e. can't you replace
all this complexity with generic seq_file/seq
at was the last update
that slabtop got, so it is indicative of the impending OOM situation
that occurred.
> Changelog from v2:
> 1.) Converted to Radix trees, not RB-tree [Zhiyong, Dave Chinner]
> 2.) Added memory shrinker [Dave Chinner]
I haven't looked at the shrinker, but c
esystem. Filesystems can make use of that information
how they please (whether in the kernel or via userspace tools), but
having filesystem specific interfaces and implementations of the
same functionality is extremely wasteful. Let's do it once, and do
it right the first time. ;)
Cheer
/mnt/scratch/foo ; echo ; done |
sort |uniq -c
39 Ouille
9962 OuilleOuille
$
XFS, on the same kernel, hardware and block device:
$ for i in `seq 0 1`; do ./a.out ; cat /mnt/scratch/foo ; echo ; done |
sort |uniq -c
40 Ouille
9961 OuilleOuille
$
So both filesystems behave
.4?
>
> commit fe2429b0966a7ec42b5fe3bf96f0f10de0a3b536
> Author: Dave Chinner
> Date: Mon Apr 23 15:58:45 2012 +1000
>
> xfs: fix buffer lookup race on allocation failure
>
> When memory allocation fails to add the page array or tht epages to
> a buffer during xfs_
From: Dave Chinner
Connect up the VFS hot tracking support so XFS filesystems can make
use of it.
Signed-off-by: Dave Chinner
---
fs/xfs/xfs_mount.h |1 +
fs/xfs/xfs_super.c |9 +
2 files changed, 10 insertions(+)
diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h
index
thread+0x93/0xa0
[ 200.064574] [] kernel_thread_helper+0x4/0x10
[ 200.064574] [] ? __init_kthread_worker+0x40/0x40
[ 200.064574] [] ? gs_change+0x13/0x13
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&
oking at timestamped event traces. Hence 300s (5
minutes) makes a lot more sense as a period for updates...
> /*
> * The following comments explain what exactly comprises a unit of heat.
> *
> diff --git a/include/linux/hot_tracking.h b/include/linux/hot_tracking.h
> index 711417
and
> migration, as described above.
I can't see how this is a manageable interface. It is not
persistent, so after every filesystem mount you'd have to set the
flag on all your inodes again. Hence, for the moment, I'd suggest
that dropping per-inode tracking control until all the
On Tue, Oct 16, 2012 at 11:38:35AM +, Arnd Bergmann wrote:
> On Tuesday 16 October 2012, Jaegeuk Kim wrote:
> > On Monday 15 October 2012, Dave Chinner wrote:
> > > On Sun, Oct 14, 2012 at 03:19:37PM +, Arnd Bergmann wrote:
> > > > On Sunday 14 October
On Tue, Oct 16, 2012 at 11:27:48AM +0200, William Dauchy wrote:
> Hello Dave,
>
> Thanks for your reply.
>
> On Tue, Oct 16, 2012 at 1:21 AM, Dave Chinner wrote:
> > You're running a CONFIG_XFS_DEBUG kernel. If you can reproduce the
> > problem with CONFIG_XFS_D
liar with xattrs in depth.
>
> Unfortunately, "system" is not implemented in f2fs yet. :(
If you've already implemented the user.* namespace, then it's
trivial to support the other namespaces - it's just prefixing the
xattrs with the appropriate string instead of &q
On Tue, Nov 20, 2012 at 02:42:48PM -0500, Jeff Moyer wrote:
> Dave Chinner writes:
>
> > And requeuing work from one workqueue to the next is something that
> > we can avoid. We know at IO submission time (i.e.
> > xfs_vm_direct_io)) whether an fsync completion is going
On Tue, Nov 20, 2012 at 08:45:03PM +0100, Torsten Kaiser wrote:
> On Tue, Nov 20, 2012 at 12:53 AM, Dave Chinner wrote:
> >[] mark_held_locks+0x7e/0x130
> >[] lockdep_trace_alloc+0x63/0xc0
> >[] kmem_cache_alloc+0x35/0xe0
> >
301 - 400 of 2159 matches
Mail list logo
