Specifically, the following bugs are fixed in this patch:
1) zdb wasn't getting the correct device size when the vdev is a
block device. In Solaris, fstat64() returns the device size but
in Linux an ioctl() is needed.
2) We were opening block devices with O_DIRECT, which caused pread64()
to fail with EINVAL due to memory alignment issues. This was fixed by
the previous umem cache alignment fix in stub implementation to align
objects correctly. But we still needed to add a check for the error here.
3) We also make sure that we don't try to open a block device in write
mode in userspace. This shouldn't happen, because zdb opens devices
in read-only mode, and ztest only uses files.
In vn_open(), if fstat64() returned an error, the real errno
was being obscured by calling close().
Add error handling for both pwrite64() calls in vn_rdwr().
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>
The intent here is to fully remove the previous Solaris thread
implementation so we don't need to simulate both Solaris kernel
and user space thread APIs. The few user space consumers of the
thread API have been updated to use the kthread API. In order
to support this we needed to more fully support the kthread API
and that means not doing crazy things like casting a thread id
to a pointer and using that as was done before. This first
implementation is not effecient but it does provide all the
corrent semantics. If/when performance becomes and issue we
can and should just natively adopt pthreads which is portable.
Let me finish by saying I'm not proud of any of this and I would
love to see it improved. However, this slow implementation does
at least provide all the correct kthread API semantics whereas
the previous method of casting the thread ID to a pointer was
dodgy at best.
Brian Behlendorf
Ricardo M. Correia