On Tue, 2007-12-11 at 17:00 -0800, Zach Brown wrote:
Hisashi Hifumi wrote:
Hi.
Current dio has some problems:
1, In ext3 ordered, dio write can return with EIO because of the race
between invalidation of
a page and jbd. jbd pins the bhs while committing journal so
On Thu, 2007-11-01 at 10:10 -0800, Badari Pulavarty wrote:
On Thu, 2007-11-01 at 11:51 -0400, Chris Mason wrote:
On Thu, 01 Nov 2007 08:38:57 -0800
Badari Pulavarty [EMAIL PROTECTED] wrote:
On Wed, 2007-10-31 at 13:40 -0400, Chris Mason wrote:
On Wed, 31 Oct 2007 08:14:21 -0800
On Wed, 2007-10-31 at 13:40 -0400, Chris Mason wrote:
On Wed, 31 Oct 2007 08:14:21 -0800
Badari Pulavarty [EMAIL PROTECTED] wrote:
I tried data=writeback mode and it didn't help :(
Ouch, so much for the easy way out.
unable to release the page 262070
bh c000211b9408 flags
On Thu, 2007-11-01 at 11:51 -0400, Chris Mason wrote:
On Thu, 01 Nov 2007 08:38:57 -0800
Badari Pulavarty [EMAIL PROTECTED] wrote:
On Wed, 2007-10-31 at 13:40 -0400, Chris Mason wrote:
On Wed, 31 Oct 2007 08:14:21 -0800
Badari Pulavarty [EMAIL PROTECTED] wrote:
I tried data
On Tue, 2007-10-30 at 18:58 -0400, Chris Mason wrote:
On Tue, 30 Oct 2007 13:54:05 -0800
Badari Pulavarty [EMAIL PROTECTED] wrote:
On Tue, 2007-10-30 at 13:54 -0400, Chris Mason wrote:
On Tue, 30 Oct 2007 10:27:04 -0800
Badari Pulavarty [EMAIL PROTECTED] wrote:
Hi
Hi,
While testing hotplug memory remove, I ran into this issue. Given a
range of pages hotplug memory remove tries to migrate those pages.
migrate_pages() keeps failing to migrate pages containing pagecache
pages for reiserfs files. I noticed that reiserfs doesn't have
-migratepage() ops. So,
On Tue, 2007-10-30 at 13:54 -0400, Chris Mason wrote:
On Tue, 30 Oct 2007 10:27:04 -0800
Badari Pulavarty [EMAIL PROTECTED] wrote:
Hi,
While testing hotplug memory remove, I ran into this issue. Given a
range of pages hotplug memory remove tries to migrate those pages
On Mon, 2007-09-17 at 12:29 -0700, Mingming Cao wrote:
On Fri, 2007-09-14 at 11:53 -0700, Mingming Cao wrote:
jbd/jbd2: Replace slab allocations with page cache allocations
From: Christoph Lameter [EMAIL PROTECTED]
JBD should not pass slab pages down to the block layer.
Use page
On Thu, 2007-07-05 at 10:11 -0700, Zach Brown wrote:
the BUG_ON(). But unfortunately, our perf. team is able reproduce the
problem.
What are they doing to reproduce it? How much setup does it take?
Huge OLTP run :(
Debug indicated that, the ret2 == 1 :(
That could be consistent
: remove bogus refcounting BUG_ON
Badari Pulavarty reported a case of this BUG_ON is triggering during
testing. It's completely bogus and should be removed.
It's trying to notice if we left references to the dio hanging around in
the sync case. They should have been dropped as IO completed while
Hi Zach,
One of our perf. team ran into this while doing some runs.
I didn't see anything obvious - it looks like we converted
async IO to synchronous one. I didn't spend much time digging
around.
Is this a known issue ? Any ideas ?
Thanks,
Badari
[ cut here ]
kernel
On Mon, 2007-05-14 at 15:14 +0530, Bharata B Rao wrote:
From: Bharata B Rao [EMAIL PROTECTED]
Subject: ext3 whiteout support
Introduce whiteout support for ext3.
Signed-off-by: Bharata B Rao [EMAIL PROTECTED]
Signed-off-by: Jan Blunck [EMAIL PROTECTED]
---
fs/ext3/dir.c |
On Mon, 2007-05-14 at 15:10 +0530, Bharata B Rao wrote:
From: Jan Blunck [EMAIL PROTECTED]
Subject: Introduce union stack.
Adds union stack infrastructure to the dentry structure and provides
locking routines to walk the union stack.
Signed-off-by: Jan Blunck [EMAIL PROTECTED]
On Mon, 2007-05-14 at 15:10 +0530, Bharata B Rao wrote:
From: Jan Blunck [EMAIL PROTECTED]
Subject: Introduce union stack.
Adds union stack infrastructure to the dentry structure and provides
locking routines to walk the union stack.
...
--- /dev/null
+++ b/include/linux/dcache_union.h
On Thu, 2007-04-12 at 06:48 +0200, Nick Piggin wrote:
http://www.kernel.org/pub/linux/kernel/people/npiggin/patches/new-aops/
2.6.21-rc6-new-aops*
New aops patchset against 2.6.21-rc6.
Building modules, stage 2.
MODPOST 558 modules
WARNING: .cont_prepare_write [fs/hfsplus/hfsplus.ko]
On Thu, 2007-04-05 at 04:08 +0200, Nick Piggin wrote:
On Wed, Apr 04, 2007 at 04:32:24PM -0700, Badari Pulavarty wrote:
On Wed, 2007-04-04 at 16:17 -0700, Mark Fasheh wrote:
On Wed, Apr 04, 2007 at 04:05:19PM -0700, Badari Pulavarty wrote:
Hmm.. Okay, only filesystems that could return
On Wed, 2007-04-04 at 15:10 -0700, Mark Fasheh wrote:
On Mon, Apr 02, 2007 at 02:09:34PM +0200, Nick Piggin wrote:
Updated aops patchset against 2.6.21-rc5.
http://www.kernel.org/pub/linux/kernel/people/npiggin/patches/new-aops/
Thanks again for pushing this stuff out Nick.
Fwiw, I
On Wed, 2007-04-04 at 16:17 -0700, Mark Fasheh wrote:
On Wed, Apr 04, 2007 at 04:05:19PM -0700, Badari Pulavarty wrote:
Hmm.. Okay, only filesystems that could return AOP_TRUNCATED_PAGE
are ocf2 and gfs2. Now that both of them are switched to have
write_begin()/write_end(), why do we need
On Tue, 2007-04-03 at 01:49 +0200, Nick Piggin wrote:
On Mon, Apr 02, 2007 at 04:14:59PM -0700, Badari Pulavarty wrote:
On Mon, 2007-04-02 at 14:09 +0200, Nick Piggin wrote:
Updated aops patchset against 2.6.21-rc5.
http://www.kernel.org/pub/linux/kernel/people/npiggin/patches/new
On Tue, 2007-04-03 at 01:58 +0200, Nick Piggin wrote:
On Mon, Apr 02, 2007 at 01:44:59PM -0700, Badari Pulavarty wrote:
On Mon, 2007-04-02 at 14:09 +0200, Nick Piggin wrote:
Updated aops patchset against 2.6.21-rc5.
http://www.kernel.org/pub/linux/kernel/people/npiggin/patches/new
On Tue, 2007-04-03 at 11:31 +0200, Nick Piggin wrote:
On Tue, Apr 03, 2007 at 02:08:53AM +0200, Nick Piggin wrote:
BTW, I will take a shot at ext4 tomorrow.
Thanks, so long as you think ext3 is looking OK?
BTW. is it a known issue that ext3 fails fsx-linux? (I tried 2.6.21-rc3
On Mon, 2007-04-02 at 14:09 +0200, Nick Piggin wrote:
Updated aops patchset against 2.6.21-rc5.
http://www.kernel.org/pub/linux/kernel/people/npiggin/patches/new-aops/
Files/dirs are 2.6.21-rc5-new-aops*
Here is the ext4 support for it. This is a simple port from
ext3 code. Ran fsx
On Mon, 2007-04-02 at 14:09 +0200, Nick Piggin wrote:
Updated aops patchset against 2.6.21-rc5.
http://www.kernel.org/pub/linux/kernel/people/npiggin/patches/new-aops/
Files/dirs are 2.6.21-rc5-new-aops*
Contains numerous fixes from Mark and myself -- I'd say the core code is
getting
On Mon, 2007-04-02 at 14:09 +0200, Nick Piggin wrote:
Updated aops patchset against 2.6.21-rc5.
http://www.kernel.org/pub/linux/kernel/people/npiggin/patches/new-aops/
Files/dirs are 2.6.21-rc5-new-aops*
Contains numerous fixes from Mark and myself -- I'd say the core code is
getting
On Mon, 2007-04-02 at 14:09 +0200, Nick Piggin wrote:
Updated aops patchset against 2.6.21-rc5.
http://www.kernel.org/pub/linux/kernel/people/npiggin/patches/new-aops/
Files/dirs are 2.6.21-rc5-new-aops*
[EMAIL PROTECTED] linux-2.6.21-rc5]# make -j8 modules
CHK
On Mon, 2007-04-02 at 14:09 +0200, Nick Piggin wrote:
Updated aops patchset against 2.6.21-rc5.
http://www.kernel.org/pub/linux/kernel/people/npiggin/patches/new-aops/
Sorry to send you so many silly fixes, but I though it would
be easy to review individual ones.
Thanks,
Badari
---
On Mon, 2007-04-02 at 14:09 +0200, Nick Piggin wrote:
Updated aops patchset against 2.6.21-rc5.
http://www.kernel.org/pub/linux/kernel/people/npiggin/patches/new-aops/
Files/dirs are 2.6.21-rc5-new-aops*
ext3_write_begin() is computing start incorrectly.
Thanks,
Badari
---
On Mon, 2007-04-02 at 14:09 +0200, Nick Piggin wrote:
Updated aops patchset against 2.6.21-rc5.
http://www.kernel.org/pub/linux/kernel/people/npiggin/patches/new-aops/
Files/dirs are 2.6.21-rc5-new-aops*
One more cleanup. index is unused.
BTW, I will take a shot at ext4 tomorrow.
(If you
On Fri, 2007-03-02 at 09:16 -0600, Eric Sandeen wrote:
Badari Pulavarty wrote:
Amit K. Arora wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode operation fallocate
Amit K. Arora wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode operation fallocate, for persistent preallocation. The new
system call, as Andrew suggested, will look like:
On Tue, 2005-07-26 at 15:52 -0700, Andrew Morton wrote:
Mingming Cao [EMAIL PROTECTED] wrote:
Here is the updated patch from Badari for delayed allocation for ext3.
Delayed allocation defers block allocation from prepare-write time to
page writeout time.
For data=writeback only, yes?
Nir Tzachar wrote:
On Wed, 2005-07-20 at 20:14 -0700, Badari Pulavarty wrote:
Nir Tzachar wrote:
hello list.
can someone please explain the exact semantics the get_block_t function
(which is passed to mpage_readpage(s)) should implement??
i could not find any documentation, and existing
Nir Tzachar wrote:
hello list.
can someone please explain the exact semantics the get_block_t function
(which is passed to mpage_readpage(s)) should implement??
i could not find any documentation, and existing code kind of baffled
me...
my current understanding goes like this:
if the block
On Sun, 2005-07-17 at 19:47 -0600, Andreas Dilger wrote:
On Jul 17, 2005 10:40 -0700, Mingming Cao wrote:
@@ -373,6 +373,7 @@ struct ext3_inode {
#define EXT3_MOUNT_BARRIER 0x2 /* Use block barriers */
#define EXT3_MOUNT_NOBH0x4 /* No bufferheads */
On Tue, 2005-04-19 at 13:41, Martin Jambor wrote:
1) Currently none of the generic helper routines can handle this.
We need to add support to do these, but still somehow make the
routines generic enough for every ones use.
I'm quite happy about most of them. I can't see how we could
On Tue, 2005-04-19 at 04:22, Nikita Danilov wrote:
Badari Pulavarty [EMAIL PROTECTED] writes:
[...]
Yes. Its possible to do what you want to. I am currently working on
adding delayed allocation support to ext3. As part of that, We
As you most likely already know, Alex Thomas already
On Tue, 2005-04-19 at 08:04, Alex Tomas wrote:
Badari Pulavarty (BP) writes:
you can introduce one more bit to page-flags
BP Agreed. I was hoping to avoid it as much as I can.
well, you're gonna modify mpage api anyway ...
Okay, I will give a serious look then. Last time, I tried
Alex Tomas wrote:
Nikita Danilov (ND) writes:
In order to do the correct accounting, we need to mark a page
to indicate if we reserved a block or not. One way to do this,
to use page-private to indicate this. But then, all the generic
I believe one can use PG_mappedtodisk bit in
Martin Jambor wrote:
Hi all,
I am a member of a group that implements a filesystem that allocates
disk blocks to in-memory blocks lazily, that means, the decision is
made just before the data are actually sent to disk. Moreover, when
cached pages are modified, the data can be (and almost certainly
the correspondence
with buffer heads all through. So would the above be a complete
no-no ?
Regards
Suparna
On Fri, Mar 04, 2005 at 06:02:35PM +0300, Alex Tomas wrote:
On 03 Mar 2005 17:12:14 -0800
Badari Pulavarty [EMAIL PROTECTED] wrote:
One more thing, we need to keep in mind is - we need to make
On Thu, 2005-03-03 at 00:33, Suparna Bhattacharya wrote:
Since the performance improvements seen so far are quite encouraging,
and momentum is picking up so well, I started looking through the
patches from Alex ... just a quick code walkthrough to get a hang
of it and think about what kind of
On Wed, 2005-02-16 at 11:09, Dave Kleikamp wrote:
On Wed, 2005-02-16 at 10:37 -0800, Badari Pulavarty wrote:
Yes. page-private is assumed for the bufferhead usage. Do you really
need for handling page-private for non-bufferhead usage ?
For what it's worth, I'm working on some changes
On Wed, 2005-02-16 at 11:43, Dave Kleikamp wrote:
On Wed, 2005-02-16 at 11:28 -0800, Badari Pulavarty wrote:
On Wed, 2005-02-16 at 11:09, Dave Kleikamp wrote:
On Wed, 2005-02-16 at 10:37 -0800, Badari Pulavarty wrote:
Yes. page-private is assumed for the bufferhead usage. Do you
On Mon, 2005-02-14 at 18:57, Andrew Morton wrote:
Badari Pulavarty [EMAIL PROTECTED] wrote:
Most of DB2 customers use filesystem for their database. Under the load,
they complain that entire memory in the system is used by filesystem
pagecache, freememory is very low and system starts
On Tue, 2005-02-15 at 09:54, Andrew Morton wrote:
Badari Pulavarty [EMAIL PROTECTED] wrote:
Yep. nobh_prepare_write() doesn't add any bufferheads. But
we call block_write_full_page() even for nobh case, which
does create bufferheads, attaches to the page and operates
on them
On Tue, 2005-02-15 at 11:07, Nikita Danilov wrote:
Andrew Morton [EMAIL PROTECTED] writes:
Badari Pulavarty [EMAIL PROTECTED] wrote:
Yep. nobh_prepare_write() doesn't add any bufferheads. But
we call block_write_full_page() even for nobh case, which
does create bufferheads
On Sat, 2005-02-12 at 15:29, Alex Tomas wrote:
Badari Pulavarty (BP) writes:
UP, after:
[EMAIL PROTECTED] root]# time /work/tests/fwrite /test/fff 64 1
real0m21.452s user0m0.026s sys 0m6.105s
[EMAIL PROTECTED] root]# time /work/tests/fwrite /test/fff 64 1
On Mon, 2005-02-14 at 14:50, William Lee Irwin III wrote:
On Mon, Feb 14, 2005 at 01:40:58PM -0800, Andrew Morton wrote:
Seems about right. There's also the buffer_heads_over_limit logic in
mm/vmscan.c and fs/buffer.c. That logic has a hole in that it requires
that there be a highmem
On Mon, 2005-02-14 at 13:40, Andrew Morton wrote:
Badari Pulavarty [EMAIL PROTECTED] wrote:
I see that as part of bufferheads to page association, we get a
ref. on the page.
create_empty_buffers() - attach_page_buffers() - page_cache_get()
I also see that this reference get
Alex Tomas wrote:
Badari Pulavarty (BP) writes:
BP Test: writes 10,000 blocks of 64k and does fdatasync().
The patch doesn't apply ;) after a minor correction
I've tested the patch too:
SMP, before:
[EMAIL PROTECTED] root]# time /work/tests/fwrite /test/fff 64 1
real0m17.748s user
Alex Tomas wrote:
Badari Pulavarty (BP) writes:
BP Test: writes 10,000 blocks of 64k and does fdatasync().
The patch doesn't apply ;) after a minor correction
I've tested the patch too:
...
UP, after:
[EMAIL PROTECTED] root]# time /work/tests/fwrite /test/fff 64 1
real0m21.452s user
On Fri, 2005-02-11 at 15:58, Andrew Morton wrote:
Badari Pulavarty [EMAIL PROTECTED] wrote:
Due to lack of interesting suggestions to solve
mpage_writepages() - ext3_writeback_writepage() problem,
I fixed it in the dumbest possible way.
I've actually forgotten what the problem
On Fri, 2005-02-11 at 15:58, Andrew Morton wrote:
Badari Pulavarty [EMAIL PROTECTED] wrote:
Due to lack of interesting suggestions to solve
mpage_writepages() - ext3_writeback_writepage() problem,
I fixed it in the dumbest possible way.
I've actually forgotten what the problem
On Wed, 2005-02-09 at 18:05, Bryan Henderson wrote:
I see much larger IO chunks and better throughput. So, I guess its
worth doing it
I hate to see something like this go ahead based on empirical results
without theory. It might make things worse somewhere else.
Do you have an
On Thu, 2005-02-10 at 10:00, Bryan Henderson wrote:
Don't you think, filesystems submitting biggest chunks of IO
possible is better than submitting 1k-4k chunks and hoping that
IO schedulers do the perfect job ?
No, I don't see why it would better. In fact intuitively, I think the I/O
On Thu, 2005-02-10 at 15:12, Stephen C. Tweedie wrote:
Hi,
On Thu, 2005-02-10 at 20:21, Andrew Morton wrote:
But I still don't understand why this can't happen
thro original code ..
what am i missing ?
presumably there are never any dirty pages or inodes when we run
Hi,
Here is my first cut at adding writepages() support for
ext3 writeback mode.
I have not done any performance analysis on the patch,
so try it at your own risk.
Please let me know, if I am completely off or its a
stupid idea.
Thanks,
Badari
--- linux-2.6.10.org/fs/ext3/inode.c
Andrew Morton wrote:
Badari Pulavarty [EMAIL PROTECTED] wrote:
Here is my first cut at adding writepages() support for
ext3 writeback mode.
Looks sane from a brief scan.
Well, not really..
mpage_writepages() could end up calling ext3_writeback_writepage()
in confused case thro ..
*ret
On Wed, 2005-02-09 at 08:37, Stephen C. Tweedie wrote:
Hi,
On Wed, 2005-02-09 at 16:18, Badari Pulavarty wrote:
I am trying to understand journaling code in ext3.
Can some one enlighten me, why we need journal start
and stop in ext3_writeback_writepage() ? The block
allocation
Hi Andrew,
I was wondering why mpage_writepage() is only static ?
Is the expectation that, filesystems use
.writepage == block_full_write_page
.writepages == mpage_writepages
? I am little confused on why we have 2 different ways to
do things ? block_full_write_page() seems to
On Thu, 2005-02-03 at 09:00, Sonny Rao wrote:
Well it seems to work, here's my (rather ugly) patch.
I'm doing some performance comparisons now.
Sonny
Interesting.. Why did you create a nobh_prepare_write() ?
mpage_writepages() can handle pages with buffer heads
attached.
And also, are
61 matches
Mail list logo
