| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
| |
warnings in sbin/hastd/lzf.c are only emitted for i386 and amd64, and
there they can be safely ignored.
MFC after: 1 week
|
|
|
|
|
| |
Inspired by: r228555
MFC after: 1 week
|
|
|
|
|
| |
Detected by: clang
MFC after: 1 week
|
|
|
|
|
| |
Found by: Clang Static Analyzer
MFC after: 1 week
|
|
|
|
|
|
|
| |
always return 0.
Found by: Clang Static Analyzer
MFC after: 1 week
|
|
|
|
|
| |
Found by: Clang Static Analyzer
MFC after: 1 week
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
| |
the race.
MFC after: 3 days
|
|
|
|
|
|
|
| |
- Introduce hio_clear() function for clearing hio before returning it
onto free queue.
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
| |
write. This way on first connection we will synchronize only the extents that
were modified during the lifetime of primary node, not entire GEOM provider.
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
|
|
|
| |
so we can always find the file, even after daemonizing and changing
working directory to /.
MFC after: 1 week
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
| |
and don't bother trying in the future.
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
|
|
| |
reordering won't make the actual write to be committed before marking
the coresponding extent as dirty.
It can be disabled in configuration file.
If BIO_FLUSH is not supported by the underlying file system we log a warning
and never send BIO_FLUSH again to that GEOM provider.
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
| |
- Add missing 'if' in comment.
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
| |
pjdlog versions will log problem to syslog when application is running in
background.
MFC after: 3 days
|
|
|
|
|
|
| |
modify errno.
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
Approved by: pjd (mentor)
|
|
|
|
|
| |
Approved by: pjd (mentor)
MFC after: 3 days
|
|
|
|
|
|
|
|
| |
disk if needed. This should fix a potential case when extents are cleared in
activemap but metadata is not updated on disk.
Suggested by: pjd
Approved by: pjd (mentor)
|
|
|
|
|
|
|
|
| |
stating if we need to update activemap on disk. This makes keepdirty
serve its purpose -- to reduce number of metadata updates.
Discussed with: pjd
Approved by: pjd (mentor)
|
|
|
|
| |
X-MFC after: capsicum merge
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
| |
It would be too noisy to log it as a proper warning as CAPABILITIES are not
compiled into GENERIC by default.
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
only receiving the data. In r220271 the unused directions were
disabled using shutdown(2).
Unfortunately, this broke automatic receive buffer sizing, which
currently works only for connections in ETASBLISHED state. It was a
root cause of the issue reported by users, when connection between
primary and secondary could get stuck.
Disable the code introduced in r220271 until the issue with automatic
buffer sizing is not resolved.
Reported by: Daniel Kalchev <daniel@digsys.bg>, danger, sobomax
Tested by: Daniel Kalchev <daniel@digsys.bg>, danger
Approved by: pjd (mentor)
MFC after: 1 week
|
|
|
|
| |
Requested by: Mikolaj Golub
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sending. What happens otherwise is that the sender splits all the
traffic into 32k chunks, while the receiver is waiting for the whole
packet. Then for a certain packet sizes, particularly 66607 bytes in
my case, the communication stucks to secondary is expecting to
read one chunk of 66607 bytes, while primary is sending two chunks
of 32768 bytes and third chunk of 1071. Probably due to TCP windowing
and buffering the final chunk gets stuck somewhere, so neither server
not client can make any progress.
This patch also protect from short reads, as according to the manual
page there are some cases when MSG_WAITALL can give less data than
expected.
MFC after: 3 days
|
|
|
|
|
|
|
| |
node. There is no use in doing this for synchronization requests.
Approved by: pjd (mentor)
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
| |
requests as well as number of activemap updates.
Number of BIO_WRITEs and activemap updates are especially interesting, because
if those two are too close to each other, it means that your workload needs
bigger number of dirty extents. Activemap should be updated as rarely as
possible.
MFC after: 1 week
|
|
|
|
|
|
|
| |
to use ioctl(2). This is why we can't use capsicum for now to sandbox
secondary. Capsicum is still used to sandbox hastctl.
MFC after: 1 week
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
| |
MFC after: 3 weeks
|
|
|
|
|
|
|
| |
tcp4://0.0.0.0:8457
tcp6://[::]:8457
MFC after: 3 weeks
|
|
|
|
| |
MFC after: 3 weeks
|
|
|
|
| |
MFC after: 3 weeks
|
|
|
|
| |
MFC after: 3 weeks
|