[PATCH] Added store_barrier() for S390

Signed-off-by: Jan Blunck <jblunck@suse.de>

[PATCH] Fixed the Makefile in btt/

Signed-off-by: Jan Blunck <jblunck@suse.de>

[PATCH] bug in btt/output.c

This patch fixes a copy'n paste bug.

[PATCH] BTT: Improve correctness of average block size merged

Made merge average block size predicated by IOs issued.

[PATCH] email update

[PATCH] Ignore PC packets in btt

BTT isn't really meant to trace those, and is causing problems with some
seek additions to btt I'm working on.

[PATCH] Fixup relayfs references and kill kernel patch

2.6.17 has shipped and has support for blktrace, so no need to
carry around the older 2.6.16 patch anymore.

[PATCH] Support for logging metadata IO requests

[PATCH] Support for readahead tracing

These are the userspace changes to allow blktrace to distinguish
readahead from non-readahead reads.

[PATCH] Fixup git web reference

[PATCH] btt: finalize the INLINE fixup

[PATCH] btt: Kill DO_INLINE and add -g

[PATCH] Add Alan's btt tool

[PATCH] docs updates: relayfs->debugfs

documentation still mentions relayfs, but I believe debugfs is correct.
Small fix attached.

[PATCH] blktrace.c should ignore SIGPIPE

After sending a SIGINT to a "blktrace .. | blkparse .. " pipeline,
occasionally I would not be able to run blktrace again. On my next run
of the same pipeline I would get the following error:

cs411vm:/usr/src/bt# ./blktrace -d /dev/sdb -o - | ./blkparse -i -
BLKTRACESETUP: No such file or directory
Failed to start trace on /dev/sdb

After rebooting, I could reproduce this by starting the pipeline, and
kicking off a big write and sending a SIGINT to blktrace. The following
is what I used for a write:

while [ 1 ]
do
    dd if=/dev/zero of=/test/write bs=1M
done

It seemed like blktrace was not handling signals correctly, so I
strace'd the process to see what was happening.

Sure enough:

--- SIGINT (Interrupt) @ 0 (0) ---
ioctl(3, 0x1275, 0xb7fa6000)            = 0
sigreturn()                             = ? (mask now [])
write(1, "O\0\0\0\20\0\200\0\0\0\0\0\0\0\0\0\7taeN3\1\0\257R\260"...,
4096) = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
+++ killed by SIGPIPE +++

Any idea what clean-up is not happening? I tried to figure it out, but
my only work-around was a reboot.

My patch against 2.6.17-rc3 just tells blktrace to ignore SIGPIPE.
Nothing crazy. :) blktrace already does enough error checking elsewhere
to handle a bad write.

On a completely unrelated note, the write_data function calls fwrite,
which will not return -1 on error. Instead you'll need to use ferror to
check if there was a problem. I'm not sure if this is a cause of any
bugs, but it seemed worth mentioning.

Furthermore, I updated the URLs in the documentation to point at a valid
git repo.

[PATCH] fread/fwrite error handling

Need to check ferror(), not return value. Thanks to Alex Polvi.

[PATCH] blktrace: fix sendfile problem with > buf_size xmits

Basically, it add buf_size, buf_nr and page_size to the net header and
this info is put into each tip, for easy access in mmap_subbuf().  The
global buf_size, etc is still used by clients, since the global value is
all they need (for clients, the tip is filled in with the global values
anyway, so that mmap_subbuf() can use them, maybe the tip->buf_size
should be used everywhere instead for consistency and only use the
global values for initial args.  Also, each tip doesn't really need to
have these values, they could be stored in tip->device but I thought it
would be easier and quicker to access tip->buf_size rather than
tip->device->buf_size).  Actually, this data only needs to be sent once
per trace, but since there's no header covering the entire trace, sends
it each time.  Could be an optimization to make later...

I've tested it using sendfile over the network with different buffer
sizes, and with normal non-sendfile network and non-network tracing
straight to disk, and haven't seen any problems.  Each test generated a
little over 1Gb of trace data in a little under 2 minutes, just under 23
million events after parsing, so it looks to me like it's doing the job
at this point...

[PATCH] Remove sysfs bits from kernel patch to match 2.6.16+

[PATCH] Rename kernel patch to 2.6.16 proper.

[PATCH] Update references to kernel patch and its inclusion in mainline

[PATCH: Change remap format to have mapped-to information on the left of the ->

Pretty self-explanatory, works fine for MD devices. Looking into DM
devices next (I think that _may_ take a kernel change).

[PATCH] blktrace: fix get_subbuf() leak

[PATCH] blktrace: sendfile() poll can use -1 timeout with the flush change

[PATCH] blktrace: only print one connection info per client

[PATCH] kernel: remember to flush relay channel on trace stop

[PATCH] blktrace: fixes for the new net client sendfile

[PATCH] kernel: drop POLLMSG hack again

[PATCH] kernel: update to -rc6

[PATCH] blktrace: remember to check flush_subbuf() return value

Also label 'maxlen' as unused instead of using casting tricks.

[PATCH] blktrace: per-cpu net connections

We can get reliable poll() without POLLMSG tricks, if we open a
net connection per CPU.

[PATCH] blktrace: handle case where output directory is not set

[PATCH] kernel: update kernel patch to include Toms read/sendfile consolidation

[PATCH] blktrace: make sendfile usage the default

[PATCH] kernel: -rc5 update

[PATCH] blkprase: binary dump capability + notify added

Here is a proposed patch which would allow blkparse to dump its output
to a binary file (in addition to the ascii output). It adds a new '-d
<file>' parameter.

The purpose of this would be to allow for the easier handling of the
collected data by analysis tools. [Rather than having to parse the
textual output from blkparse, or duplicate the collation efforts of
blkparse itself.]

[PATCH] kernel: relay files are now in debugfs

[PATCH] blktrace: relay files are now in debugfs

[PATCH] Mark as 0.99.1

[PATCH] blktrace: add __for_each_foo() for nc's, and fix crash on bad realloc

[PATCH] blktrace: fix possible crash on exit without ever opening an ofile

[PATCH] blktrace: support multiple network connections

[PATCH] blktrace: make sure net traces for multiple devices end up in same dir

[PATCH] blktrace: make net server dropped count be per-device

Require client to send a close event for each device.

[PATCH] kernel: update relayfs to set POLLMSG on subbuffer switch

[PATCH] blktrace: reduce context switches a lot, event count fix, etc

Transmit dropped events over the net as well, so the other end know if
we lost events.  Use POLLMSG from relayfs to indicate subbuf switch.

[PATCH] kernel: update to latest patch

[PATCH] blktrace: remove padding logic, it's not needed with the new sendfile()

[PATCH] blktrace: get rid of signal hacks in accepting new connections

[PATCH] README and blkrawverify minor update

Don't create an output file if the input argument is bogus or fails

[PATCH] blktrace: no need to track ts->offset anymore

[PATCH] kernel: update to fix padding read

[PATCH] blktrace: serialize sendfile sendout, then we can use poll reliably

[PATCH] kernel: last minute typo in kernel commit...

[PATCH] kernel: redo the relayfs ->sendfile implementation

[PATCH] blktrace: is_done() typo...

[PATCH] blktrace: missed net_sendfile argument update

[PATCH] blktrace: sendfile() improvements

[PATCH] blktrace: valid magic in received header always

[PATCH] blktrace: only do ioctl stop on local trace

[PATCH] blktrace: tip_open_output() cleanup

[PATCH] blktrace: store server output in client-date directory

Otherwise it's hard to do multiple traces without overwriting data.

[PATCH] blktrace: stop trace on SIGINT to allow drain

[PATCH] blktrace: ->fd and ->pfd init in net client mode

[PATCH] blktrace: final (hopefully) data read stat updates

[PATCH] blktrace: net server stat fixes

[PATCH] blktrace: bad ->data_read increment, and poll() delay fix for sendfile()

[PATCH] blktrace: use send() for last data on quit in sendfile() path

We need to do that, as we can only use full subbufs in the sendfile() path.

[PATCH] blktrace: be a little more conservative on 'ready' subbuf bytes

[PATCH] kernel: update to -rc4, include changes for sendfile() support

[PATCH] blktrace: improve sendfile support (requires kernel change)

Merge branch 'master' of ssh://axboe@router.home.kernel.dk/data/git/blktrace

[PATCH] blktrace: don't truncate/open local files when in net client mode

[PATCH] blktrace: bad alloc in sendfile() handler

[PATCH] kernel: update to -rc3 (has little fixes/optimizations, too)

[PATCH] blktrace: don't leak the accepted socket fd on reconnect

[PATCH] blktrace: one more round up of data transfer

[PATCH] blktrace: round up data read to nearest kb

[PATCH] blktrace: show incoming connection

[PATCH] blktrace: allow quit when waiting for repeat connection

[PATCH] blktrace: proper end-of-run cleanup for restart

[PATCH] blktrace: fill ops in net tip as well

[PATCH] blktrace: allow client/server to signal end-of-run properly

[PATCH] blktrace/README: update to include description of new net parameters

[PATCH] verify_blkparse: -W warning

[PATCH] blktrace: add -s sendfile option (doesn't work right now)

[PATCH] blktrace: add ->ops for the read/get/flush methods

[PATCH] blktrace: various net related fixes (accounting, stats, etc)

[PATCH] blktrace: need to free ts->buf for networked transfer

[PATCH] blktrace: fix network support, don't use sendfile() yet

We need relayfs changed for that to work (which I only have half-done)

[PATCH] blktrace: first cut at adding network support

[PATCH] blkrawverify: check and convert data appropriately

[PATCH] check_data_endianess left in half-done state

[PATCH] blkparse: __u32 -> pid_t

[PATCH] kernel patch update again

[PATCH] blkparse: ignore multiple process pid <-> name notifications

This can happen if you are doing multiple traces at the same time, then
you would get a notification after a new trace has been set up.

[PATCH] blkparse: start unification of ppi and ppm

[PATCH] kernel: update to work with latest Linus -git tree

[PATCH] kernel: update patch to match ->comm changes in blkparse

[PATCH] Shrink the trace by 1/3 by removing ->comm[16]

We now send notify messages out when we see a new process, so we don't
need to repeatedly send the same 16 bytes of name info everytime.

[PATCH] Pin the mmap'ed output buffers in ram