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. -- Dave _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
