ahkok / sreadahead Goto Github PK

With most distributions, we know better than "after Ns" when the boot
sequence has finished.

This patch from my fixes branch:

http://bazaar.launchpad.net/~scott/sreadahead/fixes/revision/36

allows -t 0 to mean "wait forever" (ie. until SIGTERM)

What steps will reproduce the problem?
1. Patch does not apply
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

I made the following change in sreadahead.c to make the trace work (near
line 479):
        unmount = chdir("/sys/kernel/debug/tracing");
        if (unmount == 0) {
                chdir("/sys/kernel/debug");
        } else {
Instead of:
        unmount = chdir("/sys/kernel/debug/tracing");
        if (unmount != 0) {
sreadahead was giving the following error messages and failing to create a
pack file before I made this change:
Unable to disable tracing
: No such file or directory
Unable to open readahead file
: No such file or directory

I'd send a patch, but this is a pretty simple change and I actually don't
know of the top of my head how to generate a patch.

What steps will reproduce the problem?
1. Patch does not apply
2. Manually apply patch (see attachment)

2. Install sreadahead to start early in boot
3. Pack file of size 0 is created

And 

4. echo open >/sys/kernel/debug/tracing/current_tracer 
5. echo 1 >/sys/kernel/debug/tracing/tracing_enabled
6. Run some commands that open files.
7. No data in /sys/kernel/debug/tracing/trace

What is the expected output?
Pack file should contain some entries, and the trace should contain some
entries.

What version of the product are you using? On what operating system?
1.0, x86_64 Debian Linux, 2.6.28.2

Please provide any additional information below.
The kernel patch was obviously not intended for 2.6.28.2, since it didn't
apply, so manually applying (and fixing names like using DEFINE_TRACE
instead of DECLARE_TRACE) may not be good enough.
It would be nice if there was a patch that applies to 2.6.28.2, and has
been tested to work with it.

Hi

In the 1.0 version, I find that we use a sort_ra_by_name() to replace the
original sort. In the new sort function, we sort all the records by file
names. Isn't this implementation lost the read order of files? Pls correct
me if wrong.

Is this by design, or a bug?

Thanks,
Kangkai

What steps will reproduce the problem?
1. compile on powerpc
2.
3.

What is the expected output? What do you see instead?
no warning because of missing ioprio support

What version of the product are you using? On what operating system?
v1.0 / on debian lenny/powerpc g3

Please provide any additional information below.

in fact there are two issues
1. my compiler need #waring pragma not #warn
2. NR_ioprio_set is 273 on powerpc

--- sreadahead.c.orig   2009-01-27 20:51:46.000000000 +0100
+++ sreadahead.c        2009-01-29 20:17:34.228607244 +0100
@@ -41,8 +41,11 @@
 #elif defined(__x86_64__)
 #  define HAVE_IO_PRIO
 #  define __NR_ioprio_set 251
+#elif defined(__powerpc__)
+#  define HAVE_IO_PRIO
+#  define __NR_ioprio_set 273
 #else /* not fatal */
-#  warn "Architecture does not support ioprio modification"
+#  warning "Architecture does not support ioprio modification"
 #endif
 #define IOPRIO_WHO_PROCESS 1
 #define IOPRIO_CLASS_IDLE 3

Any solution to compile sreadahead for an ARM?
Thanks & regards

Simon P.

A bug in sreadahead.c will prevent a trace from finishing when the debugfs
has been mounted.

If debugfs is mounted, it will cd into /sys/kernel/debug/tracing. If that
fails, then it will mount its own private version of debugfs, and cd into
that at the equivalence path of /sys/kernel/debug/ .

The rest of the code assumes that the program is in /sys/kernel/debug/ or
the private alternative. 

I have attached a patch to fix this issue.

[deleted issue]

What steps will reproduce the problem?
1. Download sreadahead-1.0
2. Unpack
3. make

What is the expected output? What do you see instead?
I expect sreadahead to be built.
Instead I get an error:
sreadahead.c:1: error: CPU you selected does not support x86-64 instruction set

What version of the product are you using? On what operating system?
1.0, Linux, Debian/sid

Please provide any additional information below.
To fix I changed "-march=i686" in the Makefile with
"-march=native".

The attached patch (against svn revision 31) changes sreadahead to metion
the -t/--time option in the internal usage summary.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?
Trying to use sreadahead tool on android target to decrease bootup time .
But sreaahesd.c are not getting compiled against bionic library.

What version of the product are you using? On what operating system?
sreadahesd-1.0

Please provide any additional information below.

Below is the error message---------




/tmp/ccIfKOOt.o: In function `one_thread':
/home/zafar/spreadahead/sreadahead-1.0/sreadahead.c:177: undefined
reference to `__sync_fetch_and_add_4'
/tmp/ccIfKOOt.o: In function `readahead_one':
/home/zafar/spreadahead/sreadahead-1.0/sreadahead.c:166: undefined
reference to `readahead'
/tmp/ccIfKOOt.o: In function `one_thread':
/home/zafar/spreadahead/sreadahead-1.0/sreadahead.c:177: undefined
reference to `__sync_fetch_and_add_4'
collect2: ld returned 1 exit status
make: *** [sreadahead] Error 1



Any help will be highly appreciated

Thank you

The home-brew filename sort isn't very efficient or fast, use qsort()
instead.  Patch available from my fixes branch:

http://bazaar.launchpad.net/~scott/sreadahead/fixes/revision/38

Hi All.
I noticed that the 1.0 changelog mentions that this release works on other
filesystems than ext3, but that the webpage still says that it's ext3 only.
I assume this is a mistake.

I don't know who makes the Ubuntu (Debian?) packages, but it carries the
same description, should I report it to someone else to get that fixed?

- Martin.

It's sometimes useful to have sreadahead stay in the foreground.  I've
committed the following patch to my fixes branch:

http://bazaar.launchpad.net/~scott/sreadahead/fixes/revision/35

Hi,
i tried to make sreadahead work with ext4 so i apply the modifications from
the patch file to my kernel
i patched the files :
fs/ext4/ioctl.c (instead fs/ext3/ioctl.c) 
fs/ext4/super.c (instead fs/ext3/super.c)
fs/ext4/ext4.h (instead of include/linux/ext3_fs.h)
include/linux/fs.h

i simply see where the modificated code goes on ext3 and pasted it at the
same code entry in ext4

the kernel compiled fine, and boot fine :)

but where running the sreadahead-packed i got a core dump (see attachment)


i forgot to say, i also modify the the proposed script 
on my configuration i replaced the ext3 with ext4 like this :
find / -type f \( -fstype ext4 -o -fstype rootfs \) > readahead.packed.new


of course i know that sreadahead is for ext3, but it would be cool if
sreadahead will work with ext4 because ext4 will be tomorow's standard as
ext3 is now

There's no reason to use a random signal like SIGUSR1 to stop tracing,
SIGTERM is just fine.

I've committed this patch to my fixes branch:

http://bazaar.launchpad.net/~scott/sreadahead/fixes/revision/34

Attached is the manpage for sreadahead (as of the current svn checkout,
e.g. including the -t option) I created for the Debian package of
sreadahead. The Debian distribution requires a manpage for every installed
binary.

I started sreadahead 1.0 on my debian sid system which uses cryptsetup to
secure some partitions. There is a /lib/cryptsetup/passfifo which
sreadahead tries to open in get_blocks, but stops trying it. As the name
suggest it is a pipe which is prw------- root root.

sreadahead is installed into /sbin, so it's manual page should be in
section 8 (which is indeed what the manual page claims to be in).

I've committed a fix for this to my fixes branch:

http://bazaar.launchpad.net/~scott/sreadahead/fixes/revision/33