* how to explain the current process?
@ 2007-03-25 14:45 Ming Zhang
2007-03-27 10:58 ` Jens Axboe
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: Ming Zhang @ 2007-03-25 14:45 UTC (permalink / raw)
To: linux-btrace
Hi All
I am using blktrace to trace a untar operation on a 400GB (already 80%
used) ext3 disk.
since journal in ext3 is at the beginning of ext3, so small LBA are
journal operations, and large lba should be inode or file data.
8,0 0 1081156 60.171965751 4929 P R [kjournald]
8,0 0 1081157 60.171965991 4929 I W 26079 + 8 [kjournald]
8,0 0 1081158 60.171966726 4929 U R [kjournald] 1
8,0 0 1081159 60.171968511 4929 D W 26079 + 8 [kjournald]
8,0 0 1081160 60.172249031 0 C W 26079 + 8 [0]
journal request
8,0 0 1081161 60.172306613 4944 Q W 733338903 + 8 [tar]
8,0 0 1081162 60.172307471 4944 G W 733338903 + 8 [tar]
8,0 0 1081163 60.172308435 4944 P R [tar]
8,0 0 1081164 60.172308798 4944 I W 733338903 + 8 [tar]
8,0 0 1081165 60.172311794 4944 Q W 733338911 + 8 [tar]
8,0 0 1081166 60.172312274 4944 M W 733338911 + 8 [tar]
file or inode
8,0 0 1081167 60.172327693 4929 U R [kjournald] 1
why here a R(read) come up? and what is the meaning of this "1" here?
8,0 0 1081168 60.172329564 4929 D W 733338903 + 16
[kjournald]
8,0 0 1081169 60.172773400 0 C W 733338903 + 16 [0]
why it is kjounrald here to "D" this request? is this because tar
already "finish" the request by writing to page cache and then when do
device io, current process is happened to be kjournald? i read the code
and it grabs current pid, so it looks so. but i still need a
confirmation here from your guys.
Thanks!
Ming
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: how to explain the current process?
2007-03-25 14:45 how to explain the current process? Ming Zhang
@ 2007-03-27 10:58 ` Jens Axboe
2007-03-27 13:44 ` Ming Zhang
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Jens Axboe @ 2007-03-27 10:58 UTC (permalink / raw)
To: linux-btrace
On Sun, Mar 25 2007, Ming Zhang wrote:
> Hi All
>
> I am using blktrace to trace a untar operation on a 400GB (already 80%
> used) ext3 disk.
>
> since journal in ext3 is at the beginning of ext3, so small LBA are
> journal operations, and large lba should be inode or file data.
>
> 8,0 0 1081156 60.171965751 4929 P R [kjournald]
> 8,0 0 1081157 60.171965991 4929 I W 26079 + 8 [kjournald]
> 8,0 0 1081158 60.171966726 4929 U R [kjournald] 1
> 8,0 0 1081159 60.171968511 4929 D W 26079 + 8 [kjournald]
> 8,0 0 1081160 60.172249031 0 C W 26079 + 8 [0]
>
> journal request
>
> 8,0 0 1081161 60.172306613 4944 Q W 733338903 + 8 [tar]
> 8,0 0 1081162 60.172307471 4944 G W 733338903 + 8 [tar]
> 8,0 0 1081163 60.172308435 4944 P R [tar]
> 8,0 0 1081164 60.172308798 4944 I W 733338903 + 8 [tar]
> 8,0 0 1081165 60.172311794 4944 Q W 733338911 + 8 [tar]
> 8,0 0 1081166 60.172312274 4944 M W 733338911 + 8 [tar]
>
> file or inode
>
> 8,0 0 1081167 60.172327693 4929 U R [kjournald] 1
>
> why here a R(read) come up? and what is the meaning of this "1" here?
It's not a read, it's an UNPLUG. And the 1 means that there was 1
request plugged when it happened.
> 8,0 0 1081168 60.172329564 4929 D W 733338903 + 16
> [kjournald]
> 8,0 0 1081169 60.172773400 0 C W 733338903 + 16 [0]
>
> why it is kjounrald here to "D" this request? is this because tar
> already "finish" the request by writing to page cache and then when do
> device io, current process is happened to be kjournald? i read the code
> and it grabs current pid, so it looks so. but i still need a
> confirmation here from your guys.
Because kjournald apparently ends up doing the dispatch. The unplug will
cause dispatch of requests, and kjournald did the unplug. So it gets to
do the dispatching as well.
--
Jens Axboe
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: how to explain the current process?
2007-03-25 14:45 how to explain the current process? Ming Zhang
2007-03-27 10:58 ` Jens Axboe
@ 2007-03-27 13:44 ` Ming Zhang
2007-03-27 13:58 ` Jens Axboe
2007-03-27 14:11 ` Ming Zhang
3 siblings, 0 replies; 5+ messages in thread
From: Ming Zhang @ 2007-03-27 13:44 UTC (permalink / raw)
To: linux-btrace
On Tue, 2007-03-27 at 12:58 +0200, Jens Axboe wrote:
> On Sun, Mar 25 2007, Ming Zhang wrote:
> > Hi All
> >
> > I am using blktrace to trace a untar operation on a 400GB (already 80%
> > used) ext3 disk.
> >
> > since journal in ext3 is at the beginning of ext3, so small LBA are
> > journal operations, and large lba should be inode or file data.
> >
> > 8,0 0 1081156 60.171965751 4929 P R [kjournald]
> > 8,0 0 1081157 60.171965991 4929 I W 26079 + 8 [kjournald]
> > 8,0 0 1081158 60.171966726 4929 U R [kjournald] 1
> > 8,0 0 1081159 60.171968511 4929 D W 26079 + 8 [kjournald]
> > 8,0 0 1081160 60.172249031 0 C W 26079 + 8 [0]
> >
> > journal request
> >
> > 8,0 0 1081161 60.172306613 4944 Q W 733338903 + 8 [tar]
> > 8,0 0 1081162 60.172307471 4944 G W 733338903 + 8 [tar]
> > 8,0 0 1081163 60.172308435 4944 P R [tar]
> > 8,0 0 1081164 60.172308798 4944 I W 733338903 + 8 [tar]
> > 8,0 0 1081165 60.172311794 4944 Q W 733338911 + 8 [tar]
> > 8,0 0 1081166 60.172312274 4944 M W 733338911 + 8 [tar]
> >
> > file or inode
> >
> > 8,0 0 1081167 60.172327693 4929 U R [kjournald] 1
> >
> > why here a R(read) come up? and what is the meaning of this "1" here?
>
> It's not a read, it's an UNPLUG. And the 1 means that there was 1
> request plugged when it happened.
>
> > 8,0 0 1081168 60.172329564 4929 D W 733338903 + 16
> > [kjournald]
> > 8,0 0 1081169 60.172773400 0 C W 733338903 + 16 [0]
> >
> > why it is kjounrald here to "D" this request? is this because tar
> > already "finish" the request by writing to page cache and then when do
> > device io, current process is happened to be kjournald? i read the code
> > and it grabs current pid, so it looks so. but i still need a
> > confirmation here from your guys.
>
> Because kjournald apparently ends up doing the dispatch. The unplug will
> cause dispatch of requests, and kjournald did the unplug. So it gets to
> do the dispatching as well.
>
why kjournald do the unplug? from the name i thought it is only for
journal (jbd)? then what pdflush does? thx.
Ming
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: how to explain the current process?
2007-03-25 14:45 how to explain the current process? Ming Zhang
2007-03-27 10:58 ` Jens Axboe
2007-03-27 13:44 ` Ming Zhang
@ 2007-03-27 13:58 ` Jens Axboe
2007-03-27 14:11 ` Ming Zhang
3 siblings, 0 replies; 5+ messages in thread
From: Jens Axboe @ 2007-03-27 13:58 UTC (permalink / raw)
To: linux-btrace
On Tue, Mar 27 2007, Ming Zhang wrote:
> On Tue, 2007-03-27 at 12:58 +0200, Jens Axboe wrote:
> > On Sun, Mar 25 2007, Ming Zhang wrote:
> > > Hi All
> > >
> > > I am using blktrace to trace a untar operation on a 400GB (already 80%
> > > used) ext3 disk.
> > >
> > > since journal in ext3 is at the beginning of ext3, so small LBA are
> > > journal operations, and large lba should be inode or file data.
> > >
> > > 8,0 0 1081156 60.171965751 4929 P R [kjournald]
> > > 8,0 0 1081157 60.171965991 4929 I W 26079 + 8 [kjournald]
> > > 8,0 0 1081158 60.171966726 4929 U R [kjournald] 1
> > > 8,0 0 1081159 60.171968511 4929 D W 26079 + 8 [kjournald]
> > > 8,0 0 1081160 60.172249031 0 C W 26079 + 8 [0]
> > >
> > > journal request
> > >
> > > 8,0 0 1081161 60.172306613 4944 Q W 733338903 + 8 [tar]
> > > 8,0 0 1081162 60.172307471 4944 G W 733338903 + 8 [tar]
> > > 8,0 0 1081163 60.172308435 4944 P R [tar]
> > > 8,0 0 1081164 60.172308798 4944 I W 733338903 + 8 [tar]
> > > 8,0 0 1081165 60.172311794 4944 Q W 733338911 + 8 [tar]
> > > 8,0 0 1081166 60.172312274 4944 M W 733338911 + 8 [tar]
> > >
> > > file or inode
> > >
> > > 8,0 0 1081167 60.172327693 4929 U R [kjournald] 1
> > >
> > > why here a R(read) come up? and what is the meaning of this "1" here?
> >
> > It's not a read, it's an UNPLUG. And the 1 means that there was 1
> > request plugged when it happened.
> >
> > > 8,0 0 1081168 60.172329564 4929 D W 733338903 + 16
> > > [kjournald]
> > > 8,0 0 1081169 60.172773400 0 C W 733338903 + 16 [0]
> > >
> > > why it is kjounrald here to "D" this request? is this because tar
> > > already "finish" the request by writing to page cache and then when do
> > > device io, current process is happened to be kjournald? i read the code
> > > and it grabs current pid, so it looks so. but i still need a
> > > confirmation here from your guys.
> >
> > Because kjournald apparently ends up doing the dispatch. The unplug will
> > cause dispatch of requests, and kjournald did the unplug. So it gets to
> > do the dispatching as well.
> >
>
> why kjournald do the unplug? from the name i thought it is only for
> journal (jbd)? then what pdflush does? thx.
kjournald does do io, hence it may get involved with
plugging/unplugging. pdflush writes out background data, other processes
may be tasks with writing out data as well.
--
Jens Axboe
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: how to explain the current process?
2007-03-25 14:45 how to explain the current process? Ming Zhang
` (2 preceding siblings ...)
2007-03-27 13:58 ` Jens Axboe
@ 2007-03-27 14:11 ` Ming Zhang
3 siblings, 0 replies; 5+ messages in thread
From: Ming Zhang @ 2007-03-27 14:11 UTC (permalink / raw)
To: linux-btrace
On Tue, 2007-03-27 at 15:58 +0200, Jens Axboe wrote:
> On Tue, Mar 27 2007, Ming Zhang wrote:
> > On Tue, 2007-03-27 at 12:58 +0200, Jens Axboe wrote:
> > > On Sun, Mar 25 2007, Ming Zhang wrote:
> > > > Hi All
> > > >
> > > > I am using blktrace to trace a untar operation on a 400GB (already 80%
> > > > used) ext3 disk.
> > > >
> > > > since journal in ext3 is at the beginning of ext3, so small LBA are
> > > > journal operations, and large lba should be inode or file data.
> > > >
> > > > 8,0 0 1081156 60.171965751 4929 P R [kjournald]
> > > > 8,0 0 1081157 60.171965991 4929 I W 26079 + 8 [kjournald]
> > > > 8,0 0 1081158 60.171966726 4929 U R [kjournald] 1
> > > > 8,0 0 1081159 60.171968511 4929 D W 26079 + 8 [kjournald]
> > > > 8,0 0 1081160 60.172249031 0 C W 26079 + 8 [0]
> > > >
> > > > journal request
> > > >
> > > > 8,0 0 1081161 60.172306613 4944 Q W 733338903 + 8 [tar]
> > > > 8,0 0 1081162 60.172307471 4944 G W 733338903 + 8 [tar]
> > > > 8,0 0 1081163 60.172308435 4944 P R [tar]
> > > > 8,0 0 1081164 60.172308798 4944 I W 733338903 + 8 [tar]
> > > > 8,0 0 1081165 60.172311794 4944 Q W 733338911 + 8 [tar]
> > > > 8,0 0 1081166 60.172312274 4944 M W 733338911 + 8 [tar]
> > > >
> > > > file or inode
> > > >
> > > > 8,0 0 1081167 60.172327693 4929 U R [kjournald] 1
> > > >
> > > > why here a R(read) come up? and what is the meaning of this "1" here?
> > >
> > > It's not a read, it's an UNPLUG. And the 1 means that there was 1
> > > request plugged when it happened.
> > >
> > > > 8,0 0 1081168 60.172329564 4929 D W 733338903 + 16
> > > > [kjournald]
> > > > 8,0 0 1081169 60.172773400 0 C W 733338903 + 16 [0]
> > > >
> > > > why it is kjounrald here to "D" this request? is this because tar
> > > > already "finish" the request by writing to page cache and then when do
> > > > device io, current process is happened to be kjournald? i read the code
> > > > and it grabs current pid, so it looks so. but i still need a
> > > > confirmation here from your guys.
> > >
> > > Because kjournald apparently ends up doing the dispatch. The unplug will
> > > cause dispatch of requests, and kjournald did the unplug. So it gets to
> > > do the dispatching as well.
> > >
> >
> > why kjournald do the unplug? from the name i thought it is only for
> > journal (jbd)? then what pdflush does? thx.
>
> kjournald does do io, hence it may get involved with
> plugging/unplugging. pdflush writes out background data, other processes
> may be tasks with writing out data as well.
so u meant kjournald need to actively flush journal and thus if journal
and data on same disk, it will take the role of plug and unplug many
times as well? then it is reasonable to see it appear so many times.
thanks.
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-03-27 14:11 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-25 14:45 how to explain the current process? Ming Zhang
2007-03-27 10:58 ` Jens Axboe
2007-03-27 13:44 ` Ming Zhang
2007-03-27 13:58 ` Jens Axboe
2007-03-27 14:11 ` Ming Zhang
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.