Under FC11 rpm builds by default add the --fortify-source option which
ensures that functions flagged with certain attributes must have their
return codes checked. Normally this is just a warning but we always
build with -Werror so this is fatal. Simply wrap the function in a
verify call to ensure we catch a failure if there is one.
With this patch applied I get the following failure 100% of the time,
I'd prefer to debug it and keep moving forward but I do not have the
time right now so I'm reverting the patch to the version which worked.
Ricardo please fix.
(gdb) bt
0 ztest_dmu_write_parallel (za=0x2aaaac898960) at
../../cmd/ztest/ztest.c:2566
1 0x0000000000405a79 in ztest_thread (arg=<value optimized out>)
at ../../cmd/ztest/ztest.c:3862
2 0x00002b2e6a7a841d in zk_thread_helper (arg=<value optimized out>)
at ../../lib/libzpool/kernel.c:131
3 0x000000379be06367 in start_thread (arg=<value optimized out>)
at pthread_create.c:297
4 0x000000379b2d30ad in clone () from /lib64/libc.so.6
This resolves previous scalabily concerns about the cost of calling
curthread which previously required a list walk. The kthread address
is now tracked as thread specific data which can be quickly returned.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Because the local 'index' variable shadows the index() function
it was replaced by 'i'. Unfortunately when I made this change
I accidentally replaced one instance with 'j' resulting in the
short decimal values being printed incorrectly.
The 2.6.30 kernel build systems sets -Wframe-larger-than=2048 which causes
a warning to be generated when an individual stack frame exceeds 2048.
This caught the spa_history_log() and dmu_objset_snapshot() functions
which declared a data structure on the stack which contained a char
array of MAXPATHLEN. This in defined to be 4096 in the linux kernel
and I imagine it is quite large under Solaris as well. Regardless, the
offending data structures were moved to the heap to correctly keep the
stack depth to a minimum. We might consider setting this value even
lower to catch additional offenders because we are expecting deep stacks.
2.6.22 API change
Unused destroy_dirty_buffers arg removed from prototype.
2.6.24 API change
Empty write barriers are now supported and we should use them.
2.6.24 API change
Size argument dropped from bio_endio and bi_end_io, because the
bi_end_io is only called once now when the request is complete.
There is no longer any need for a size argument. This also means
that partial IO's are no longer possibe and the end_io callback
should not check bi->bi_size. Finally, the return type was updated
to void.
2.6.28 API change
open/close_bdev_excl() renamed to open/close_bdev_exclusive().
2.6.29 API change
BIO_RW_SYNC renamed to BIO_RW_SYNCIO.
Modern kernel build systems at least post 2.6.16 will set this properly
so we should not. In fact post 2.6.28 the include headers have moved
under arch so the guess we make here is completely wrong. Letting
the kernel build system set this ensure it will be correct. Also
drop the ulimit from the Makefile which, not surprisingly, turns out
to be very non-portable. If your expecting failures set the ulimit
in your shell before kicking off the test suite.
Brian Behlendorf
Ricardo M. Correia