Difference between revisions of "What's bad with V1 images"

 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
Current [[images]] format is great, but sometimes we find problems with it. This page collects all we don't like about them and would like to change some time in the future (once we change this, image format version will be changed as well).
 
Current [[images]] format is great, but sometimes we find problems with it. This page collects all we don't like about them and would like to change some time in the future (once we change this, image format version will be changed as well).
  
 +
== Unused/misused/misplaced/misnamed/mistyped issues ==
 
* vma.proto vma_entry->fd is unused
 
* vma.proto vma_entry->fd is unused
 
* ipc-msg.proto ipc_msg/ipc_msg_entry names mess
 
* ipc-msg.proto ipc_msg/ipc_msg_entry names mess
Line 7: Line 8:
 
* pstree.proto: sid and pgid should NOT be there, but in core image
 
* pstree.proto: sid and pgid should NOT be there, but in core image
 
* core.proto -- padding for fpu is not used
 
* core.proto -- padding for fpu is not used
* what to do with absent image files? Backward compatibility requires we still restore, common sense -- abort. Flooding inventory with every single new image doesn't sound that great.
 
 
* core.proto -- unused (though optional) ids field
 
* core.proto -- unused (though optional) ids field
 
* clear_thread_info in per-arch members
 
* clear_thread_info in per-arch members
* it would be great to unify inotify and fanotify images into one fsnotify file
 
* currently we write checkpoint files with '''*.img''' extension, which might be confusing since this extension is a way overloaded by meaning and quite widespreaded, thus it might be worth to change extension to '''*.criu'''
 
 
* mnt_entry::fstype (in mnt.proto) should have enum fstype type
 
* mnt_entry::fstype (in mnt.proto) should have enum fstype type
 
* all IDs in image should be in uint64 format (not uint32, like in reg_file_entry), this allows us to use unified ID generator over all images
 
* all IDs in image should be in uint64 format (not uint32, like in reg_file_entry), this allows us to use unified ID generator over all images
* IPC mqueue sysctls are required, while in kernel they  can be missing
 
 
* In proto files for registers (and more) it's better to use fixed- types, rather than plain
 
* In proto files for registers (and more) it's better to use fixed- types, rather than plain
 
* use fixed32 and fixed64 where approiate instead of uint32 and uint64 https://developers.google.com/protocol-buffers/docs/proto
 
* use fixed32 and fixed64 where approiate instead of uint32 and uint64 https://developers.google.com/protocol-buffers/docs/proto
 
* flock's flag and type fields is actually too much for what is stored there
 
* flock's flag and type fields is actually too much for what is stored there
* remap image uses older bit od ID to distinguish one remap type from another, while it should be a typed field
 
 
* evenpoll's tfd ID field is always zero
 
* evenpoll's tfd ID field is always zero
 +
 +
== Other stuff ==
 +
* it would be great to unify inotify and fanotify images into one fsnotify file
 +
* currently we write checkpoint files with '''*.img''' extension, which might be confusing since this extension is a way overloaded by meaning and quite widespreaded, thus it might be worth to change extension to '''*.criu'''
 +
* Fields for IPC mqueue sysctls are required, while in kernel they  can be missing
 +
* Images structure is not natural. Some contain pb entries of a same type, some have a header of one pb type and then an array of another type or some raw data.
 +
* Pages from not-yet-COW-ed vm areas contain duplicate data
 +
 +
== Fixed ==
 +
* Too many magic values. Need common header for images? (in {{Criu|1.6}} with {{Git_commit|f5ea330c}})
 +
* Ipcns-shm image keeps objects and raw memory dumps together (in {{Criu|3.0}} with {{Git_commit|9d2e1dfe}})
 +
 +
== See also ==
 +
 +
[[Deprecation]]
  
 
[[Category:Development]]
 
[[Category:Development]]
 
[[Category:Images]]
 
[[Category:Images]]

Latest revision as of 16:06, 29 June 2017

Current images format is great, but sometimes we find problems with it. This page collects all we don't like about them and would like to change some time in the future (once we change this, image format version will be changed as well).

Unused/misused/misplaced/misnamed/mistyped issuesEdit

  • vma.proto vma_entry->fd is unused
  • ipc-msg.proto ipc_msg/ipc_msg_entry names mess
  • sk-packet.proto vs packet-sock.proto names mess (all sockets .proto files are sk-<something>)
  • core.proto blk_sigset for master thread is on task_core_entry, but should be in respective thread_core_entry
  • pstree.proto: sid and pgid should NOT be there, but in core image
  • core.proto -- padding for fpu is not used
  • core.proto -- unused (though optional) ids field
  • clear_thread_info in per-arch members
  • mnt_entry::fstype (in mnt.proto) should have enum fstype type
  • all IDs in image should be in uint64 format (not uint32, like in reg_file_entry), this allows us to use unified ID generator over all images
  • In proto files for registers (and more) it's better to use fixed- types, rather than plain
  • use fixed32 and fixed64 where approiate instead of uint32 and uint64 https://developers.google.com/protocol-buffers/docs/proto
  • flock's flag and type fields is actually too much for what is stored there
  • evenpoll's tfd ID field is always zero

Other stuffEdit

  • it would be great to unify inotify and fanotify images into one fsnotify file
  • currently we write checkpoint files with *.img extension, which might be confusing since this extension is a way overloaded by meaning and quite widespreaded, thus it might be worth to change extension to *.criu
  • Fields for IPC mqueue sysctls are required, while in kernel they can be missing
  • Images structure is not natural. Some contain pb entries of a same type, some have a header of one pb type and then an array of another type or some raw data.
  • Pages from not-yet-COW-ed vm areas contain duplicate data

FixedEdit

See alsoEdit

Deprecation