| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
Just assume sane platforms offer smart mutexes
that have a fast-path with spinlocks internally
for locks that have little to no congestion.
In all other cases, mutexes should perform better
anyways.
|
|
|
|
|
|
| |
This makes the server not set the FLAGS8_SERVER flag
when establishing an uplink connection. Useful mostly
for running a proxy on localhost for local caching.
|
|
|
|
|
| |
Early benchmarking shows that this is faster, since we don't
require another thread to wake up just to send out the request.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This requires a much shorter queue and balances hashing between
different images if the checker lags behind.
On Linux, use sync_file_range() instead of fsync() before reading
back to speed up flushing.
|
| |
|
|
|
|
| |
Counter in seconds for how long this image hasn't been used.
|
| |
|
|
|
|
|
|
| |
In case we don't use background replication a connection to an uplink
server can potentially stay around forever. This in turn would prevent
the uplink server from freeing the image as it appears to be in use.
|
|
|
|
|
|
| |
It didn't make too much sense that we only checked _maxPayload when the
reply arrived; simply don't forward a request where we already know we
won't handle the reply.
|
| |
|
|
|
|
|
|
|
| |
_backgroundReplication was still treated as a boolean flag, so a server
with BGR_NONE would reject a server with BGR_HASHBLOCK. While this still
forces the BGR_NONE proxy to replicate more than it normally would, it
seems reasonable to allow this.
|
|
|
|
| |
Don't drop runId
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Gets rid of the lastBytesSent field as well as the stats lock per
client. Cleaned and split up the messy net_clientsToJson function while
at it.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Most config settings can now be changed at runtime
using SIGHUP. This currently excludes the basePath,
listenPort, and the client and image count limits,
as well as vmdkLegacyMode.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This is a compromise; if you want to validate replicated data fairly
quickly, using this option will make background replication only kick in
when there's a "dirty" 16M block, i.e. some blocks within a 16M block
are cached locally, but not all. Completing the block makes it possible
to validate its CRC32 checksum.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
If we lost connection and then go check all known alt
servers, see if we have some pending request queued and
if so, use its offset and length for the alt server probe.
This ensures that the server being tested is able to
satisfy at least the next request we'll send.
|
|
|
|
|
|
| |
Further improving cache handling, don't keep blocks
in cache that have been requested via background replication.
It's likely these aren't needed in the near future.
|
|
|
|
|
|
|
|
| |
Now that we support sparse files, using just
fdatasync isn't safe anymore. Instead of handling
both cases differently just drop fdatasync,
the difference has probably been marginal all
along anyways.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The idea is that for full image checks, we don't want to
pollute the fs cache with gigabytes of data that won't be
needed again soon. This would certainly hurt performance
on servers that dont have hundreds of GBs of RAM.
For single block checks during replication this has the
advantage that we don't check the block in memory before
it hit the disk once, but actually flush the data to disk,
then remove it from the page cache, and only then read it
again, from disk.
TODO: Might be worth making this a config option
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The cacheFd is now moved to the uplink data structure and will
only be handled by the uplink thread.
The integrity checker now supports checking all blocks of an
image. This will be triggered automatically whenever a check for
a single block failed.
Also, if a crc check on startup fails, the image won't be discarded
anymore, but rather a full check will be initiated.
Furthermore, when calling image_updateCacheMap() on an image that
was previously complete, the cache map will now be re-initialized,
and a new uplink connection created.
|
| |
|
|
|
|
|
|
|
| |
In scenarios where the proxy is using an NFS server as
storage (for whatever crazy reason) or when the cacheFd
goes bad through e.g. a switchroot, try to re-open it
instead of just disabling caching forever.
|
| |
|
|
|
|
|
| |
read() calls are supposed to return 0 when reading at EOF,
so properly mimic that behavior.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
imageListLock was locked on twice in the call stack, which
is bad if you're using non-recursive locks.
|
| |
|