Signed-off-by: Evgenii Stratonikov <evgeniy@nspcc.ru>

Signed-off-by: Evgenii Stratonikov <evgeniy@nspcc.ru>

If we should process address based on some condition, there is no need
to read file content in memory.

Signed-off-by: Evgenii Stratonikov <evgeniy@nspcc.ru>

Some of the objects are already flushed, don't do it twice.

Signed-off-by: Evgenii Stratonikov <evgeniy@nspcc.ru>

`Update` becomes a botleneck under a heavy load.

Signed-off-by: Evgenii Stratonikov <evgeniy@nspcc.ru>

`log.With` is suitable during initialization, but in other places it induces
some overhead, even when branches with logging are not taken.

Signed-off-by: Evgenii Stratonikov <evgeniy@nspcc.ru>

Signed-off-by: Evgenii Stratonikov <evgeniy@nspcc.ru>

Signed-off-by: Evgenii Stratonikov <evgeniy@nspcc.ru>

If we should process address based on some condition, there is no need
to read file content in memory.

Signed-off-by: Evgenii Stratonikov <evgeniy@nspcc.ru>

Some of the objects are already flushed, don't do it twice.

Signed-off-by: Evgenii Stratonikov <evgeniy@nspcc.ru>

`Update` becomes a botleneck under a heavy load.

Signed-off-by: Evgenii Stratonikov <evgeniy@nspcc.ru>

`log.With` is suitable during initialization, but in other places it induces
some overhead, even when branches with logging are not taken.

Signed-off-by: Evgenii Stratonikov <evgeniy@nspcc.ru>

Signed-off-by: Evgenii Stratonikov <evgeniy@nspcc.ru>

The problem is that it can take a significant amount of time to perform while
the value is questionable.

It was initially added in 8717820 (#1462)
when write cache had completely different structure and function.
733a792 tried to optimize it in #2068, but
most of the code was subsequently deleted and as write cache is no longer a
read cache this lead to the remaining code doing only the following:
 * checking objects against the metabase
 * checking objects against the underlying long-term storage

If the first one is ever triggered (we detect non-existent object) this just
means WC is out of sync with metabase which can happen for a number of other
reasons. Lower level blobstor can also get out of sync with metabase in some
cases, so it's not like this is something unique. If we're to drop this check
we'd just flush some dead object, but then GC should still be able to remove
it if it's deleted normally. If it's some other type of race --- like WC
accepted an object and metabase not yet then we shouldn't delete it at all
for safety reasons.

Then if some valid object was previously flushed already we'll retry flushing
it again and it's not a problem, EEXIST is not an error (but #2563), so we'd
waste some time, but it's not very likely we're going to since this case is
rare.

So it should be safe to drop this useless code.

Signed-off-by: Roman Khimov <roman@nspcc.ru>

The problem is that it can take a significant amount of time to perform while
the value is questionable.

It was initially added in 8717820 (#1462)
when write cache had completely different structure and function.
733a792 tried to optimize it in #2068, but
most of the code was subsequently deleted and as write cache is no longer a
read cache this lead to the remaining code doing only the following:
 * checking objects against the metabase
 * checking objects against the underlying long-term storage

If the first one is ever triggered (we detect non-existent object) this just
means WC is out of sync with metabase which can happen for a number of other
reasons. Lower level blobstor can also get out of sync with metabase in some
cases, so it's not like this is something unique. If we're to drop this check
we'd just flush some dead object, but then GC should still be able to remove
it if it's deleted normally. If it's some other type of race --- like WC
accepted an object and metabase not yet then we shouldn't delete it at all
for safety reasons.

Then if some valid object was previously flushed already we'll retry flushing
it again and it's not a problem, EEXIST is not an error (but #2563), so we'd
waste some time, but it's not very likely we're going to since this case is
rare.

So it should be safe to drop this useless code.

Signed-off-by: Roman Khimov <roman@nspcc.ru>

The problem is that it can take a significant amount of time to perform while
the value is questionable.

It was initially added in 8717820 (#1462)
when write cache had completely different structure and function.
733a792 tried to optimize it in #2068, but
most of the code was subsequently deleted and as write cache is no longer a
read cache this lead to the remaining code doing only the following:
 * checking objects against the metabase
 * checking objects against the underlying long-term storage

If the first one is ever triggered (we detect non-existent object) this just
means WC is out of sync with metabase which can happen for a number of other
reasons. Lower level blobstor can also get out of sync with metabase in some
cases, so it's not like this is something unique. If we're to drop this check
we'd just flush some dead object, but then GC should still be able to remove
it if it's deleted normally. If it's some other type of race --- like WC
accepted an object and metabase not yet then we shouldn't delete it at all
for safety reasons.

Then if some valid object was previously flushed already we'll retry flushing
it again and it's not a problem, EEXIST is not an error (but #2563), so we'd
waste some time, but it's not very likely we're going to since this case is
rare.

So it should be safe to drop this useless code.

Signed-off-by: Roman Khimov <roman@nspcc.ru>

The problem is that it can take a significant amount of time to perform while
the value is questionable.

It was initially added in 8717820 (#1462)
when write cache had completely different structure and function.
733a792 tried to optimize it in #2068, but
most of the code was subsequently deleted and as write cache is no longer a
read cache this lead to the remaining code doing only the following:
 * checking objects against the metabase
 * checking objects against the underlying long-term storage

If the first one is ever triggered (we detect non-existent object) this just
means WC is out of sync with metabase which can happen for a number of other
reasons. Lower level blobstor can also get out of sync with metabase in some
cases, so it's not like this is something unique. If we're to drop this check
we'd just flush some dead object, but then GC should still be able to remove
it if it's deleted normally. If it's some other type of race --- like WC
accepted an object and metabase not yet then we shouldn't delete it at all
for safety reasons.

Then if some valid object was previously flushed already we'll retry flushing
it again and it's not a problem, EEXIST is not an error (but #2563), so we'd
waste some time, but it's not very likely we're going to since this case is
rare.

So it should be safe to drop this useless code.

Signed-off-by: Roman Khimov <roman@nspcc.ru>

The problem is that it can take a significant amount of time to perform while
the value is questionable.

It was initially added in 8717820 (#1462)
when write cache had completely different structure and function.
733a792 tried to optimize it in #2068, but
most of the code was subsequently deleted and as write cache is no longer a
read cache this lead to the remaining code doing only the following:
 * checking objects against the metabase
 * checking objects against the underlying long-term storage

If the first one is ever triggered (we detect non-existent object) this just
means WC is out of sync with metabase which can happen for a number of other
reasons. Lower level blobstor can also get out of sync with metabase in some
cases, so it's not like this is something unique. If we're to drop this check
we'd just flush some dead object, but then GC should still be able to remove
it if it's deleted normally. If it's some other type of race --- like WC
accepted an object and metabase not yet then we shouldn't delete it at all
for safety reasons.

Then if some valid object was previously flushed already we'll retry flushing
it again and it's not a problem, EEXIST is not an error (but #2563), so we'd
waste some time, but it's not very likely we're going to since this case is
rare.

So it should be safe to drop this useless code.

Signed-off-by: Roman Khimov <roman@nspcc.ru>