Anyone ever see fail/timeout errors like this?:
04/29/2019 12:04:20 ANR3691E The transaction failed for process
CONVERT
STGPOOL, process number 40838, because of a
transaction
timeout. (SESSION: 50394593, PROCESS: 40838)
04/29/2019 12:04:20
I'm afraid Remco is right, the server can't (or simply won't) uncompress
the older client-side compression so it will convert it compressed to the
containerpool and you will most likely get very poor deduplication on that
data.
What kind of data is it and for how long do you need to keep it?
On Th
it’s not a perfect world, AFAIK.
> On 19 Apr 2018, at 10:36, Michael Prix wrote:
>
> Hello *SMers,
>
> just out of curiosity:
> Given you have a storagepool with a legacy, non-deduplicated, file-devclass,
> inside which files are stored with "compression yes" on the clientside. This
> storagep
Hello *SMers,
just out of curiosity:
Given you have a storagepool with a legacy, non-deduplicated, file-devclass,
inside which files are stored with "compression yes" on the clientside. This
storagepool is converted to a directory-containerpool. How are the compressed
files handled during conver
