Issue 1 sparse zero write lifecycle

[aliaksandr-vasilenka-vention]

• Separates Tensors into Dense and Sparse, only places for branching are create and load
• Adds tests for Sparse-zero policy cases
• Implements Sparse-zero policy cases
• Fixes incorrect read value logic when block is missing and index is present for Sparse tensor to follow close fail path

[haydnv]

How do we handle the case where the entries in a sparse tensor (the blocks) are larger than the configured block size for a dense tensor? We should not support "unlimited block size" in any case

[aliaksandr-vasilenka-vention]

Not sure what part of code is referenced here. Could you please clarify?

[haydnv]

This is more of an architectural question. Say the block size is 4096 elements. A user creates a sparse tensor of shape [1000, 1000, 64, 64, 64] where axis 1 is the sparse axis. That means each entry on the sparse axis must be represented using multiple blocks on the filesystem (not just one per entry). Is this handled correctly now or is this something we need to address as a follow-up?

[aliaksandr-vasilenka-vention]

Need to check it out

[aliaksandr-vasilenka-vention]

To be noted:

1. For some reasons freqfs lib allows to read values for tensor even if directory with blocks for that tensor is removed physically, is it normal behaviour for freqfs or should we check it out?
2. Should we address the missing decoding logic for Result in destream lib and encoding looks like inner values encoding?
3. Currently attempt to write 0 into sparse tensor removes row inside the index and also removes block only if it empty. Is it correct?

[haydnv]

Much better! Consider a type alias for Shape and Coord, for clarity and performance:

type Coord = SmallVec<[u64; 8]>;
type Shape = SmallVec<[u64; 8]>;

[haydnv]

1. Yes freqfs is designed to prefer an in-memory cache and fall back to disk storage only to avoid an OOM error
2. Why do we need this?
3. Yes this is correct