mirror of
https://github.com/mhx/dwarfs.git
synced 2025-09-10 13:04:15 -04:00
Update TODO
This commit is contained in:
parent
2eadb48cfa
commit
894993f54c
47
TODO
47
TODO
@ -1,19 +1,10 @@
|
|||||||
filesystem_writer holds compressors for all categories:
|
- Compress long repetitions of the same byte more efficiently.
|
||||||
|
Currently, segmentation finds an overlap after about one
|
||||||
filesystem_writer::write_block(data, category);
|
window size. This goes on and on repeatedly. So we end up
|
||||||
|
with a *lot* of chunks pointing to the same segment. The
|
||||||
There's one block_manager for each category. We should probably
|
smaller the window size, the larger the number of chunks.
|
||||||
rename it to something like category_block_manager? Or even something
|
It's definitely a trade off, as storing large segments of
|
||||||
with `segmenter` in the name? Or maybe just segmenter?
|
repeating bytes is wasteful when mounting the image.
|
||||||
|
|
||||||
The new block_manager would be shared between all segmenters and take
|
|
||||||
care of providing new blocks and enforcing limits.
|
|
||||||
|
|
||||||
There might also be a segmenter_manager that would queue all segmenters
|
|
||||||
and run them in a worker group.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
- Forward compatibility
|
- Forward compatibility
|
||||||
@ -28,30 +19,6 @@ and run them in a worker group.
|
|||||||
|
|
||||||
- Mounting lots of images with shared cache?
|
- Mounting lots of images with shared cache?
|
||||||
|
|
||||||
inode -> list of fragments
|
|
||||||
|
|
||||||
categorizer returns list of fragments OR single category
|
|
||||||
|
|
||||||
fragment -> [offset, length, category]
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
TODO: with PCM audio signals, we need to categorize by:
|
|
||||||
|
|
||||||
- # of channels
|
|
||||||
- bit depth
|
|
||||||
- endian-ness
|
|
||||||
- signed-ness
|
|
||||||
- sample rate (not necessarily)
|
|
||||||
|
|
||||||
we also need to keep track of endian-ness and signed-ness
|
|
||||||
outside of the FLAC stream, as this information isn't
|
|
||||||
stored in FLAC; we could always get this information from
|
|
||||||
the metadata of the original file, but that would be a lot
|
|
||||||
more complicated than just storing two extra bits in the
|
|
||||||
block itself; we'll have to store the decoded length as
|
|
||||||
well, so this won't make a real difference
|
|
||||||
|
|
||||||
- how do we make multiple parallel block chains (categories)
|
- how do we make multiple parallel block chains (categories)
|
||||||
reproducible?
|
reproducible?
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user