writes. You can't force that
behaviour by changing the block layer code. Perhaps you could force
O_SYNC when a file is opened, if you want to experiment with worst case
generally. Not sure that makes a lot of sense, though.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe
schedulers will now
treat the IO as sync and introduce idling for the disk head. And you
definitely don't want that.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
On Tue, Jan 15 2008, Jens Axboe wrote:
On Mon, Jan 14 2008, Jens Axboe wrote:
On Mon, Jan 14 2008, Chris Mason wrote:
Hello everyone,
Here is a modified version of Jens' patch. The basic idea is to push
the mapping maintenance out of loop and down into the filesystem (ext2
On Tue, Jan 15 2008, Jens Axboe wrote:
On Tue, Jan 15 2008, Jens Axboe wrote:
On Mon, Jan 14 2008, Jens Axboe wrote:
On Mon, Jan 14 2008, Chris Mason wrote:
Hello everyone,
Here is a modified version of Jens' patch. The basic idea is to push
the mapping maintenance out
, KM_USER1);
You're using kmap_atomic, but I see no reason you can't be preempted.
Don't you need to at least disable preemption while you have stuff
atomically kmapped?
kmap_atomic() disables preemption through pagefault_disable().
--
Jens Axboe
-
To unsubscribe from this list: send the line
prio_tree_node *last_lookup;
unsigned intblkbits;
};
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jan 11 2008, Daniel Phillips wrote:
Hi Jens,
This looks really useful.
On Wednesday 09 January 2008 00:52, Jens Axboe wrote:
Disadvantages:
- The file block mappings must not change while loop is using the
file. This means that we have to ensure exclusive access to the file
On Thu, Jan 10 2008, Jens Axboe wrote:
On Wed, Jan 09 2008, Alasdair G Kergon wrote:
Here's the latest version of dm-loop, for comparison.
To try it out,
ln -s dmsetup dmlosetup
and supply similar basic parameters to losetup.
(using dmsetup version 1.02.11 or higher)
Why oh why
have is a crappy bmap() interface to get at those mappings.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jan 10 2008, Christoph Hellwig wrote:
On Thu, Jan 10, 2008 at 09:44:57AM +0100, Jens Axboe wrote:
IMHO this shouldn't be done in the loop driver anyway. Filesystems have
their own effricient extent lookup trees (well, at least xfs and btrfs
do), and we should leverage
as needed
with some very simple logic to populate-ahead. In practice that performs
as well as a pre-populated map, the first IO to a given range will just
be a little slower since we have to bmap() it.
Do you have plans to improve this area?
--
Jens Axboe
-
To unsubscribe from this list: send the line
On Thu, Jan 10 2008, Peter Zijlstra wrote:
On Thu, 2008-01-10 at 10:49 +0100, Jens Axboe wrote:
On Thu, Jan 10 2008, Peter Zijlstra wrote:
On Thu, 2008-01-10 at 08:37 +, Christoph Hellwig wrote:
Peter, any chance you could chime in here?
I have this patch to add
On Thu, Jan 10 2008, Chris Mason wrote:
On Thu, 10 Jan 2008 09:31:31 +0100
Jens Axboe [EMAIL PROTECTED] wrote:
On Wed, Jan 09 2008, Alasdair G Kergon wrote:
Here's the latest version of dm-loop, for comparison.
To try it out,
ln -s dmsetup dmlosetup
and supply similar
On Thu, Jan 10 2008, Chris Mason wrote:
On Thu, 10 Jan 2008 08:54:59 +
Christoph Hellwig [EMAIL PROTECTED] wrote:
On Thu, Jan 10, 2008 at 09:44:57AM +0100, Jens Axboe wrote:
IMHO this shouldn't be done in the loop driver anyway.
Filesystems have their own effricient extent lookup
the posted patch and the posts from Chris as well, it
basically covers everything in your email.
The patch, as posted, doesn't work if the fs moves blocks around.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More
(root, cur-parent, cur);
}
+EXPORT_SYMBOL(prio_tree_remove);
/*
* Following functions help to enumerate all prio_tree_nodes in the tree that
@@ -482,3 +485,4 @@ repeat:
goto repeat;
}
+EXPORT_SYMBOL(prio_tree_next);
--
Jens Axboe
-
To unsubscribe from this list: send the line
On Wed, Jan 09 2008, Christoph Hellwig wrote:
On Wed, Jan 09, 2008 at 09:52:32AM +0100, Jens Axboe wrote:
- The file block mappings must not change while loop is using the file.
This means that we have to ensure exclusive access to the file and
this is the bit that is currently missing
have a new slot on the box just removing any developer
motivation to work on the issue.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Oct 05 2007, Pekka Enberg wrote:
Hi,
On 10/5/07, Jens Axboe [EMAIL PROTECTED] wrote:
I'd like to second Davids emails here, this is a serious problem. Having
a reproducible test case lowers the barrier for getting the problem
fixed by orders of magnitude. It's the difference
On Fri, Oct 05 2007, Matthew Wilcox wrote:
On Fri, Oct 05, 2007 at 08:48:53AM +0200, Jens Axboe wrote:
I'd like to second Davids emails here, this is a serious problem. Having
a reproducible test case lowers the barrier for getting the problem
fixed by orders of magnitude. It's
applications. Waving some standard at them if they
complain is unlikely to impress them.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
of those things that people will complain about two releases later
saying it broke app foo.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Aug 31 2007, Christoph Lameter wrote:
On Fri, 31 Aug 2007, Jens Axboe wrote:
Could you be more specific?
Size of a single segment, for instance. Or if the bio crosses a dma
boundary. If your block is 64kb and the maximum segment size is 32kb,
then you would need to clone
On Fri, Aug 31 2007, Christoph Lameter wrote:
On Fri, 31 Aug 2007, Jens Axboe wrote:
A DMA boundary cannot be crossed AFAIK. The compound pages are aligned to
the power of two boundaries and the page allocator will not create pages
that cross the zone boundaries.
With a 64k page
On Fri, Aug 31 2007, Christoph Lameter wrote:
On Fri, 31 Aug 2007, Jens Axboe wrote:
They have nothing to do with each other, you are mixing things up. It
has nothing to do with the device being able to dma into that memory or
not, we have fine existing infrastructure to handle
On Fri, Aug 31 2007, Christoph Lameter wrote:
On Fri, 31 Aug 2007, Jens Axboe wrote:
Ok. So another solution maybe to limit the blocksizes that can be used
with a device?
That'd work for creation, but not for moving things around.
What do you mean by moving things around
On Mon, Aug 13 2007, Jens Axboe wrote:
You did not comment on the one about putting the bio destructor in
the -endio handler, which looks dead simple. The majority of cases
just use the default endio handler and the default destructor. Of the
remaining cases, where a specialized
On Mon, Aug 13 2007, Daniel Phillips wrote:
On Monday 13 August 2007 00:28, Jens Axboe wrote:
On Sun, Aug 12 2007, Daniel Phillips wrote:
Right, that is done by bi_vcnt. I meant bi_max_vecs, which you can
derive efficiently from BIO_POOL_IDX() provided the bio was
allocated
On Mon, Aug 13 2007, Daniel Phillips wrote:
On Monday 13 August 2007 00:45, Jens Axboe wrote:
On Mon, Aug 13 2007, Jens Axboe wrote:
You did not comment on the one about putting the bio destructor
in the -endio handler, which looks dead simple. The majority of
cases just use
On Mon, Aug 13 2007, Daniel Phillips wrote:
On Monday 13 August 2007 02:13, Jens Axboe wrote:
On Mon, Aug 13 2007, Daniel Phillips wrote:
On Monday 13 August 2007 00:45, Jens Axboe wrote:
On Mon, Aug 13 2007, Jens Axboe wrote:
You did not comment on the one about putting the bio
On Mon, Aug 13 2007, Daniel Phillips wrote:
On Monday 13 August 2007 03:06, Jens Axboe wrote:
On Mon, Aug 13 2007, Daniel Phillips wrote:
Of course not. Nothing I said stops endio from being called in the
usual way as well. For this to work, endio just needs to know that
one call
don't add temporary fields out of laziness, hoping that someone
will later kill it again and rewrite it in a nicer fashion. Hint: that
never happens, bloat sticks.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED
On Tue, Aug 07 2007, Daniel Phillips wrote:
On Tuesday 07 August 2007 05:05, Jens Axboe wrote:
On Sun, Aug 05 2007, Daniel Phillips wrote:
A simple way to solve the stable accounting field issue is to add a
new pointer to struct bio that is owned by the top level submitter
(normally
.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jul 18 2007, Tejun Heo wrote:
Jens Axboe wrote:
On Wed, Jul 18 2007, Tejun Heo wrote:
End of device check is done twice in __generic_make_request() and it's
fully inlined each time. Factor out bio_check_eod().
Tejun, yeah I should seperate the cleanups and put them
On Wed, Jul 18 2007, Tejun Heo wrote:
Jens Axboe wrote:
On Wed, Jul 18 2007, Tejun Heo wrote:
Jens Axboe wrote:
On Wed, Jul 18 2007, Tejun Heo wrote:
Jens Axboe wrote:
On Wed, Jul 18 2007, Tejun Heo wrote:
End of device check is done twice in __generic_make_request() and it's
fully
On Wed, Jul 18 2007, Jens Axboe wrote:
On Wed, Jul 18 2007, Tejun Heo wrote:
Jens Axboe wrote:
On Wed, Jul 18 2007, Tejun Heo wrote:
Jens Axboe wrote:
On Wed, Jul 18 2007, Tejun Heo wrote:
Jens Axboe wrote:
On Wed, Jul 18 2007, Tejun Heo wrote:
End of device check is done
On Wed, Jul 18 2007, Jens Axboe wrote:
On Wed, Jul 18 2007, Tejun Heo wrote:
Jens Axboe wrote:
On Wed, Jul 18 2007, Tejun Heo wrote:
Jens Axboe wrote:
On Wed, Jul 18 2007, Tejun Heo wrote:
Jens Axboe wrote:
On Wed, Jul 18 2007, Tejun Heo wrote:
End of device check is done
On Thu, Jul 05 2007, Tejun Heo wrote:
Hello, Jens.
Jens Axboe wrote:
On Mon, May 28 2007, Neil Brown wrote:
I think the implementation priorities here are:
1/ implement a zero-length BIO_RW_BARRIER option.
2/ Use it (or otherwise) to make all dm and md modules handle
barriers
On Sat, Jun 02 2007, Tejun Heo wrote:
Hello,
Jens Axboe wrote:
Would that be very different from issuing barrier and not waiting for
its completion? For ATA and SCSI, we'll have to flush write back cache
anyway, so I don't see how we can get performance advantage by
implementing
straight through the io scheduler.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jun 01 2007, Tejun Heo wrote:
Jens Axboe wrote:
On Thu, May 31 2007, David Chinner wrote:
On Thu, May 31, 2007 at 08:26:45AM +0200, Jens Axboe wrote:
On Thu, May 31 2007, David Chinner wrote:
IOWs, there are two parts to the problem:
1 - guaranteeing I/O ordering
2
a barrier request before that request
and previously submitted requests are on STABLE storage, then it
violates that principle. Look at the code and the various ordering
options.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL
of barriers.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 31 2007, Bill Davidsen wrote:
Jens Axboe wrote:
On Thu, May 31 2007, David Chinner wrote:
On Thu, May 31, 2007 at 08:26:45AM +0200, Jens Axboe wrote:
On Thu, May 31 2007, David Chinner wrote:
IOWs, there are two parts to the problem:
1 - guaranteeing I/O
On Thu, May 31 2007, Phillip Susi wrote:
Jens Axboe wrote:
No Stephan is right, the barrier is both an ordering and integrity
constraint. If a driver completes a barrier request before that request
and previously submitted requests are on STABLE storage, then it
violates that principle. Look
support or not), it may be
nearly as slow as a real barrier write.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
the highest pfn in the system -- in that case,
* don't waste time iterating over bio segments
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
(dunny why you explicitly dropped me off the cc/to list when replying to
my email, hence I missed it for 3 days)
On Fri, May 25 2007, Phillip Susi wrote:
Jens Axboe wrote:
A barrier write will include a flush, but it may also use the FUA bit to
ensure data is on platter. So the only situation
() would never be
needed (unless you want to do a data-less barrier, and we should
probably add that specific functionality with an empty bio instead of
providing an alternate way of doing that).
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body
to provide support for putting multiple files close
together? Ala
# e4defrag file1 file2 file3 ... fileN
I'm thinking boot speedup, gather the list of read files and put them
close on disk.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body
On Wed, Jan 17 2007, Dave Kleikamp wrote:
On Thu, 2007-01-18 at 10:18 +1100, Jens Axboe wrote:
Can you try io_schedule() and verify that things just work?
I actually did do that in the first place, but wondered if it was the
right thing to introduce the accounting changes that came
?
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jan 05 2007, Suparna Bhattacharya wrote:
On Fri, Jan 05, 2007 at 08:02:33AM +0100, Jens Axboe wrote:
On Fri, Jan 05 2007, Suparna Bhattacharya wrote:
On Thu, Jan 04, 2007 at 09:02:42AM -0800, Andrew Morton wrote:
On Thu, 4 Jan 2007 10:26:21 +0530
Suparna Bhattacharya [EMAIL
dependent on this.
Patches against next -mm would be appreciated, please. Sorry about that.
I _assume_ Jens is targetting 2.6.21?
Only if everything works perfectly, 2.6.22 is also a viable target.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel
order of the patches, what
is the fsaio target?
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
56 matches
Mail list logo
