On Wed, May 6, 2015 at 11:07 AM, Philip Martin
wrote:
> Stefan Fuhrmann writes:
>
> > Here is what I believe causes the different behaviour between
> > test runs. To support read function that may block, e.g. wait for
> > network buffers to flush, writes have been made non-blocking
> > if they d
Stefan Fuhrmann writes:
> Here is what I believe causes the different behaviour between
> test runs. To support read function that may block, e.g. wait for
> network buffers to flush, writes have been made non-blocking
> if they don't update existing cache entries. If the write lock can
> not be
On Wed, May 6, 2015 at 1:18 AM, Philip Martin
wrote:
> fs-test 44 shows a problem when multiple threads access an FSFS txn, the
> txn_dir_cache makes it possible for changes to be lost. Today I have
> been seeing this test XPASS instead of XFAIL about 1 time in 30 when
> running "./fs-test --par
fs-test 44 shows a problem when multiple threads access an FSFS txn, the
txn_dir_cache makes it possible for changes to be lost. Today I have
been seeing this test XPASS instead of XFAIL about 1 time in 30 when
running "./fs-test --parallel". I don't understand why. I see this
with 1.9.x and tru
4 matches
Mail list logo