On Wed, Aug 31 2005, Nathan Scott wrote:
> Hi Jens,
>
> On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> > Ok, updated version.
>
> One thing I found a bit awkward was the way its putting all inodes
> in the root of the relayfs namespace, with the cpuid tacked on the
> end of the
On Wed, Aug 31 2005, Nathan Scott wrote:
Hi Jens,
On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
Ok, updated version.
One thing I found a bit awkward was the way its putting all inodes
in the root of the relayfs namespace, with the cpuid tacked on the
end of the bdevname -
On Wed, Aug 31 2005, Nathan Scott wrote:
> Hi Jens,
>
> On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> > Ok, updated version.
>
> One thing I found a bit awkward was the way its putting all inodes
> in the root of the relayfs namespace, with the cpuid tacked on the
> end of the
On Wed, Aug 31 2005, Nathan Scott wrote:
> Hi Jens,
>
> On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> > Patch attached is against 2.6.13-rc6-mm2. Still a good idea to apply the
> > relayfs read update from the previous mail [*] as well.
>
> There's a small memory leak there on
On Wed, Aug 31 2005, Nathan Scott wrote:
Hi Jens,
On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
Patch attached is against 2.6.13-rc6-mm2. Still a good idea to apply the
relayfs read update from the previous mail [*] as well.
There's a small memory leak there on one of the
On Wed, Aug 31 2005, Nathan Scott wrote:
Hi Jens,
On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
Ok, updated version.
One thing I found a bit awkward was the way its putting all inodes
in the root of the relayfs namespace, with the cpuid tacked on the
end of the bdevname -
Nathan Scott writes:
> Hi Tom,
>
> On Tue, Aug 30, 2005 at 11:19:04PM -0500, Tom Zanussi wrote:
> > You're right, it should be using simple_rmdir rather than
> > simple_unlink for removing directories. Thanks for sending the patch,
>
> No problem.
>
> > which I've modified a bit to
On Wed, Aug 31, 2005 at 02:33:10PM +1000, Nathan Scott wrote:
> ...
> On an unrelated note, are there any known issues with using epoll
> on relayfs file descriptors? I'm having a few troubles, and just
> wondering if its me doing something silly, or if its known to not
> work...? Symptoms of
Hi Tom,
On Tue, Aug 30, 2005 at 11:19:04PM -0500, Tom Zanussi wrote:
> You're right, it should be using simple_rmdir rather than
> simple_unlink for removing directories. Thanks for sending the patch,
No problem.
> which I've modified a bit to avoid splitting the rmdir/unlink cases
> into
Nathan Scott writes:
> Hi there,
>
> On Wed, Aug 31, 2005 at 09:48:23AM +1000, Nathan Scott wrote:
> > ...
> > # find /relay
> > /relay
> > /relay/block
> > /relay/block/sdd
> > /relay/block/sdd/trace3
> > /relay/block/sdd/trace2
> > /relay/block/sdd/trace1
> > /relay/block/sdd/trace0
Hi there,
On Wed, Aug 31, 2005 at 09:48:23AM +1000, Nathan Scott wrote:
> ...
> # find /relay
> /relay
> /relay/block
> /relay/block/sdd
> /relay/block/sdd/trace3
> /relay/block/sdd/trace2
> /relay/block/sdd/trace1
> /relay/block/sdd/trace0
> /relay/block/sdb
> /relay/block/sdb/trace3
>
Hi Jens,
On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> Ok, updated version.
One thing I found a bit awkward was the way its putting all inodes
in the root of the relayfs namespace, with the cpuid tacked on the
end of the bdevname - I was a bit confused at first when a trace of
Hi Jens,
On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> Patch attached is against 2.6.13-rc6-mm2. Still a good idea to apply the
> relayfs read update from the previous mail [*] as well.
There's a small memory leak there on one of the start-tracing
error paths (relay_open
Hi Jens,
On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
Patch attached is against 2.6.13-rc6-mm2. Still a good idea to apply the
relayfs read update from the previous mail [*] as well.
There's a small memory leak there on one of the start-tracing
error paths (relay_open
Hi Jens,
On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
Ok, updated version.
One thing I found a bit awkward was the way its putting all inodes
in the root of the relayfs namespace, with the cpuid tacked on the
end of the bdevname - I was a bit confused at first when a trace of
sdd
Hi there,
On Wed, Aug 31, 2005 at 09:48:23AM +1000, Nathan Scott wrote:
...
# find /relay
/relay
/relay/block
/relay/block/sdd
/relay/block/sdd/trace3
/relay/block/sdd/trace2
/relay/block/sdd/trace1
/relay/block/sdd/trace0
/relay/block/sdb
/relay/block/sdb/trace3
Nathan Scott writes:
Hi there,
On Wed, Aug 31, 2005 at 09:48:23AM +1000, Nathan Scott wrote:
...
# find /relay
/relay
/relay/block
/relay/block/sdd
/relay/block/sdd/trace3
/relay/block/sdd/trace2
/relay/block/sdd/trace1
/relay/block/sdd/trace0
/relay/block/sdb
Hi Tom,
On Tue, Aug 30, 2005 at 11:19:04PM -0500, Tom Zanussi wrote:
You're right, it should be using simple_rmdir rather than
simple_unlink for removing directories. Thanks for sending the patch,
No problem.
which I've modified a bit to avoid splitting the rmdir/unlink cases
into separate
On Wed, Aug 31, 2005 at 02:33:10PM +1000, Nathan Scott wrote:
...
On an unrelated note, are there any known issues with using epoll
on relayfs file descriptors? I'm having a few troubles, and just
wondering if its me doing something silly, or if its known to not
work...? Symptoms of the
Nathan Scott writes:
Hi Tom,
On Tue, Aug 30, 2005 at 11:19:04PM -0500, Tom Zanussi wrote:
You're right, it should be using simple_rmdir rather than
simple_unlink for removing directories. Thanks for sending the patch,
No problem.
which I've modified a bit to avoid
On Mon, Aug 29 2005, Nathan Scott wrote:
> On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> > ...
> > Patch attached is against 2.6.13-rc6-mm2. Still a good idea to apply the
> > relayfs read update from the previous mail [*] as well.
>
> Hi Jens,
>
> There's a minor config botch in
On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> ...
> Patch attached is against 2.6.13-rc6-mm2. Still a good idea to apply the
> relayfs read update from the previous mail [*] as well.
Hi Jens,
There's a minor config botch in there, I get this:
scripts/kconfig/conf -s
On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
...
Patch attached is against 2.6.13-rc6-mm2. Still a good idea to apply the
relayfs read update from the previous mail [*] as well.
Hi Jens,
There's a minor config botch in there, I get this:
scripts/kconfig/conf -s
On Mon, Aug 29 2005, Nathan Scott wrote:
On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
...
Patch attached is against 2.6.13-rc6-mm2. Still a good idea to apply the
relayfs read update from the previous mail [*] as well.
Hi Jens,
There's a minor config botch in there, I
On Wed, Aug 24 2005, Jens Axboe wrote:
> On Wed, Aug 24 2005, Nathan Scott wrote:
> > On Wed, Aug 24, 2005 at 09:08:10AM +0200, Jens Axboe wrote:
> > > ...
> > > This isn't msec precision, it's usec. sched_clock() is in ns! I already
> > > decided that msec is too coarse, but usec _should_ be
On Wed, Aug 24 2005, Nathan Scott wrote:
> On Wed, Aug 24, 2005 at 09:08:10AM +0200, Jens Axboe wrote:
> > ...
> > This isn't msec precision, it's usec. sched_clock() is in ns! I already
> > decided that msec is too coarse, but usec _should_ be enough.
>
> Right you are (I was thinking
On Wed, Aug 24, 2005 at 09:08:10AM +0200, Jens Axboe wrote:
> ...
> This isn't msec precision, it's usec. sched_clock() is in ns! I already
> decided that msec is too coarse, but usec _should_ be enough.
Right you are (I was thinking m-for-micro, not m-for-milli in my head ;)
- but still, there
On Wed, Aug 24 2005, Nathan Scott wrote:
> On Tue, Aug 23, 2005 at 02:32:36PM +0200, Jens Axboe wrote:
> > Hi,
> >
> > This is a little something I have played with. It allows you to see
> > exactly what is going on in the block layer for a given queue. Currently
> > it can logs request queueing
On Wed, Aug 24 2005, Nathan Scott wrote:
> Hi Jens,
>
> On Tue, Aug 23, 2005 at 02:32:36PM +0200, Jens Axboe wrote:
> > ...
> > + t.pid = current->pid;
> > ...
> > +/*
> > + * The trace itself
> > + */
> > +struct blk_io_trace {
> > + u32 magic; /* MAGIC << 8 | version
Hi Jens,
On Tue, Aug 23, 2005 at 02:32:36PM +0200, Jens Axboe wrote:
> ...
> + t.pid = current->pid;
> ...
> +/*
> + * The trace itself
> + */
> +struct blk_io_trace {
> + u32 magic; /* MAGIC << 8 | version */
> + u32 sequence; /* event number */
> +
Hi Jens,
On Tue, Aug 23, 2005 at 02:32:36PM +0200, Jens Axboe wrote:
...
+ t.pid = current-pid;
...
+/*
+ * The trace itself
+ */
+struct blk_io_trace {
+ u32 magic; /* MAGIC 8 | version */
+ u32 sequence; /* event number */
+ u64 time;
On Wed, Aug 24 2005, Nathan Scott wrote:
Hi Jens,
On Tue, Aug 23, 2005 at 02:32:36PM +0200, Jens Axboe wrote:
...
+ t.pid = current-pid;
...
+/*
+ * The trace itself
+ */
+struct blk_io_trace {
+ u32 magic; /* MAGIC 8 | version */
+ u32 sequence;
On Wed, Aug 24 2005, Nathan Scott wrote:
On Tue, Aug 23, 2005 at 02:32:36PM +0200, Jens Axboe wrote:
Hi,
This is a little something I have played with. It allows you to see
exactly what is going on in the block layer for a given queue. Currently
it can logs request queueing and
On Wed, Aug 24, 2005 at 09:08:10AM +0200, Jens Axboe wrote:
...
This isn't msec precision, it's usec. sched_clock() is in ns! I already
decided that msec is too coarse, but usec _should_ be enough.
Right you are (I was thinking m-for-micro, not m-for-milli in my head ;)
- but still, there
On Wed, Aug 24 2005, Nathan Scott wrote:
On Wed, Aug 24, 2005 at 09:08:10AM +0200, Jens Axboe wrote:
...
This isn't msec precision, it's usec. sched_clock() is in ns! I already
decided that msec is too coarse, but usec _should_ be enough.
Right you are (I was thinking m-for-micro, not
On Wed, Aug 24 2005, Jens Axboe wrote:
On Wed, Aug 24 2005, Nathan Scott wrote:
On Wed, Aug 24, 2005 at 09:08:10AM +0200, Jens Axboe wrote:
...
This isn't msec precision, it's usec. sched_clock() is in ns! I already
decided that msec is too coarse, but usec _should_ be enough.
On Tue, Aug 23, 2005 at 02:32:36PM +0200, Jens Axboe wrote:
> Hi,
>
> This is a little something I have played with. It allows you to see
> exactly what is going on in the block layer for a given queue. Currently
> it can logs request queueing and building, dispatches, requeues, and
>
On Tue, Aug 23, 2005 at 02:32:36PM +0200, Jens Axboe wrote:
Hi,
This is a little something I have played with. It allows you to see
exactly what is going on in the block layer for a given queue. Currently
it can logs request queueing and building, dispatches, requeues, and
completions.
Ah,
38 matches
Mail list logo