blktrace & btrace usability

blktrace & btrace usability

[Linda Walsh]

I was examining the SuSE10.3 boot process and noted
it is setup to start & stop blktrace while the system
is booting.  Odd think is that it checks to verify that
the root file system is of type "ext3". 

Is that a "SuSEism" or is there some reason why it wouldn't
work with any file system?

linda

Re: blktrace & btrace usability

[Jens Axboe]

On Fri, Jan 18 2008, Linda Walsh wrote:
> I was examining the SuSE10.3 boot process and noted
> it is setup to start & stop blktrace while the system
> is booting.  Odd think is that it checks to verify that
> the root file system is of type "ext3". 
> 
> Is that a "SuSEism" or is there some reason why it wouldn't
> work with any file system?

Interesting, I never noticed that before. Don't know why they check for
ext3, perhaps their post processing tools map blocks to files and only
works for ext3?

-- 
Jens Axboe

Re: blktrace & btrace usability

[Linda Walsh]

Jens Axboe wrote:
> On Fri, Jan 18 2008, Linda Walsh wrote:
>   
>> I was examining the SuSE10.3 boot process and noted
>> it is setup to start & stop blktrace while the system
>> is booting.  Odd think is that it checks to verify that
>> the root file system is of type "ext3". 
>>
>> Is that a "SuSEism" or is there some reason why it wouldn't
>> work with any file system?
>>     
>
> Interesting, I never noticed that before. Don't know why they check for
> ext3, perhaps their post processing tools map blocks to files and only
> works for ext3?
>   
--- 
    Would be nice if they left a comment to that effect.
    ext2 should be the same, and I think xfs has all the
data needed to process it under a perl script -- xfs_bmap,
for example, prints off all of the blocks used by a file (so
it's easy to compute fragmentation).

    They don't seem to include a util in the blktrace package
to map blocks to to files.  Anyway, you answer my question --
blktracing doesn't rely on something ext3 specific.

thanks,
linda

Re: blktrace & btrace usability

[Jens Axboe]

On Fri, Jan 18 2008, Linda Walsh wrote:
> Jens Axboe wrote:
> >On Fri, Jan 18 2008, Linda Walsh wrote:
> >  
> >>I was examining the SuSE10.3 boot process and noted
> >>it is setup to start & stop blktrace while the system
> >>is booting.  Odd think is that it checks to verify that
> >>the root file system is of type "ext3". 
> >>
> >>Is that a "SuSEism" or is there some reason why it wouldn't
> >>work with any file system?
> >>    
> >
> >Interesting, I never noticed that before. Don't know why they check for
> >ext3, perhaps their post processing tools map blocks to files and only
> >works for ext3?
> >  
> --- 
>    Would be nice if they left a comment to that effect.
>    ext2 should be the same, and I think xfs has all the
> data needed to process it under a perl script -- xfs_bmap,
> for example, prints off all of the blocks used by a file (so
> it's easy to compute fragmentation).
> 
>    They don't seem to include a util in the blktrace package
> to map blocks to to files.  Anyway, you answer my question --
> blktracing doesn't rely on something ext3 specific.

There's definitely nothing fs specific in blktrace. IIRC, Olaf Kirch
wrote something called fsmap while at SUSE. Perhaps that is a clue to
what they are doing there?

-- 
Jens Axboe

Re: blktrace & btrace usability

[Jan Blunck]

On Fri, Jan 18, Linda Walsh wrote:

> I was examining the SuSE10.3 boot process and noted
> it is setup to start & stop blktrace while the system
> is booting.  Odd think is that it checks to verify that
> the root file system is of type "ext3". 
> Is that a "SuSEism" or is there some reason why it wouldn't
> work with any file system?

Maybe I can help here.

blktrace is used by the preload package. The preload package is capable of
remapping blocks for faster booting. Therefore we need the blktrace
output. But we only have a remapper for ext3.

Hope that helps,
Jan

Re: blktrace & btrace usability

[Linda Walsh]

Jan Blunck wrote:
> blktrace is used by the preload package. The preload package is capable of
> remapping blocks for faster booting. Therefore we need the blktrace
> output. But we only have a remapper for ext3.
>   
----
    I wondered about that, but the blktrace package doesn't containg
any utility for remapping blocks. The blktrace-0.99.3-12 package
included in OSuse-10.3, I only see utilities "blkparse, blktrace, btrace,
blkrawverify, btt, and verify_blktrace". 

    Was it left out by accident?  ---or---

    If the remapping is in a separate package, then shouldn't
the blktrace package "just" do the block tracing, regardless
of file type (i.e. in typical unix fashion, it does its part, and
another util (a block-re-arranger) does its part...? 

    Having blktrace do it's thing no matter what filesystem
follows might encourage or enable someone to write re-arrangers
for other filesystems...(?)  After all, xfs already has
one block-rearranger program (for what little it is needed)
in "xfs_fsr".  Does ext3 have something similar now? 

    Was the ext3 block re-arranging tool supposed to be
in the blktrace package? 

thanks,
linda

Re: blktrace & btrace usability

[Jan Blunck]

On Tue, Jan 22, Linda Walsh wrote:

> Jan Blunck wrote:
>> blktrace is used by the preload package. The preload package is capable of
>> remapping blocks for faster booting. Therefore we need the blktrace
>> output. But we only have a remapper for ext3.
>>   
> ----
>    I wondered about that, but the blktrace package doesn't containg
> any utility for remapping blocks. The blktrace-0.99.3-12 package
> included in OSuse-10.3, I only see utilities "blkparse, blktrace, btrace,
> blkrawverify, btt, and verify_blktrace". 
>    Was it left out by accident?  ---or---

No, this is the reason why I said "blktrace is used by the preload
package". The ext3remapper is part of the preload package.

>    If the remapping is in a separate package, then shouldn't
> the blktrace package "just" do the block tracing, regardless
> of file type (i.e. in typical unix fashion, it does its part, and
> another util (a block-re-arranger) does its part...? 

Yes it is just doing that. If you only have a remapper for ext3 (I wasn't
aware of XFS) there is no point in gathering the blktrace data for other
filesystem. boot.blktrace, which is the script you are refering to is part of
the preload package. Remember that we haven't changed blktrace that it only
works for ext3 or something similar.

>    Having blktrace do it's thing no matter what filesystem
> follows might encourage or enable someone to write re-arrangers
> for other filesystems...(?)  After all, xfs already has
> one block-rearranger program (for what little it is needed)
> in "xfs_fsr".  Does ext3 have something similar now? 

Yes, the ext3remapper written by Jan Kara.

Re: blktrace & btrace usability

[Linda Walsh]

Jan Blunck wrote:
> On Tue, Jan 22, Linda Walsh wrote:
>
>   
>> Jan Blunck wrote:
>>     
>>> blktrace is used by the preload package. The preload package is capable of
>>> remapping blocks for faster booting. Therefore we need the blktrace
>>> output. But we only have a remapper for ext3.
>>>  
>>>       
>> ----
>>    I wondered about that, but the blktrace package doesn't containg
>> any utility for remapping blocks. The blktrace-0.99.3-12 package
>> included in OSuse-10.3, I only see utilities "blkparse, blktrace, btrace,
>> blkrawverify, btt, and verify_blktrace". 
>>    Was it left out by accident?  ---or---
>>     
>
> No, this is the reason why I said "blktrace is used by the preload
> package". The ext3remapper is part of the preload package.
>   
----
    Ahh...I'm sorry, I didn't know that the blktrace rc-scripts were
unrelated to the blktrace package and that by preload package you meant
a package named "preload" (I thought preload was some other phase
that I didn't know about that happened before other packages
were processed, or something).  I got confused by the names (no
idea why...*cough*)...  I'm not sure why the package, "preload", got
installed and "chkconfig'ed on" when I have no ext{23} disks.

    I have "personal" issues with each new version adding more
automatically run "services".  Reminds me more and more of WinXP with
all its auto-start boot progs & services and how it initially (pre-SP2),
installed with most services turned on (even though they weren't
needed by most users).  In a similar way, SuSE organizes its
rpms to "require" features (packages) that I don't want and don't
need (avahi an apple-ad-hoc networking util with most of gnome
requiring its presence).

    xfs has a file-system re-organizer, but its design goal
(probably ~10 years back) was simply to coalesce discontiguous
file parts to speed up speed sensitive real-time video streaming.
If it was deemed important, the existing xfs_fsr might be
adaptable...

    Sorry for my confusion..., from the names "boot.blktrace" &
"stopblktrace", I thought they were general scripts for recording
the "boot+rc" block actions -- not specifically for the
package named "preload".

-l