Quoting Dave Hansen (dave@xxxxxxxxxxxxxxxxxx): > On Mon, 2009-02-23 at 17:49 -0600, Serge E. Hallyn wrote: > > Quoting Dave Hansen (dave@xxxxxxxxxxxxxxxxxx): > > > Introduce a files_struct counter to indicate whether a particular > > > file_struct has ever contained a file which can not be > > > checkpointed. This flag is a one-way trip; once it is set, it may > > > not be unset. > > > > > > We assume at allocation that a new files_struct is clean and may > > > be checkpointed. However, as soon as it has had its files filled > > > from its parent's, we check it for real in __scan_files_for_cr(). > > > At that point, we mark it if it contained any uncheckpointable > > > files. > > > > > > We also check each 'struct file' when it is installed in a fd > > > slot. This way, if anyone open()s or managed to dup() an > > > unsuppored file, we can catch it. > > > > So what is the point of tagging the files_struct counter and > > making it a one-way trip? Why not just check every file at > > checkpoint time? > > We need both. > > This allows us to tell where and when we went wrong. Take a process > that's been running for a month. After 5 days it did something random > to keep it from being checkpointed. You're going to have forgotten all > about it 25 days later. This gives us an opportunity to spit into dmesg > or just plain log it. It also gives the app some ability to reflect and > see what its uncheckpointable attributes are. Hmm. In that case, rather than refuse checkpoint, I prefer that we make this a footnote in the /proc/$$/checkpointable output. -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
