You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue was originally created before Brimcap existed and the specific draft proposal below for implementation is probably no longer relevant. However, since the Brim+Brimcap workflow still includes "dragging a pcap into the app", the question of what could be done if the pcap is compressed still seems relevant.
Add support to the pcap ingest api in zqd to support compressed pcaps. Since we need an uncompressed pcap to support slicing, the implementation for this should create an uncompressed form of the pcap that is stored in the space's data directory, along with the pcap index. The uncompressed pcap should get deleted when the space itself is deleted.
For Brim users with large compressed pcaps, this will cause some increased storage space, but I think this is where the slice-to-pcap feature is most useful.
The text was updated successfully, but these errors were encountered:
This issue was originally created before Brimcap existed and the specific draft proposal below for implementation is probably no longer relevant. However, since the Brim+Brimcap workflow still includes "dragging a pcap into the app", the question of what could be done if the pcap is compressed still seems relevant.
Add support to the pcap ingest api in zqd to support compressed pcaps. Since we need an uncompressed pcap to support slicing, the implementation for this should create an uncompressed form of the pcap that is stored in the space's data directory, along with the pcap index. The uncompressed pcap should get deleted when the space itself is deleted.
For Brim users with large compressed pcaps, this will cause some increased storage space, but I think this is where the slice-to-pcap feature is most useful.
The text was updated successfully, but these errors were encountered: