Hi!
> > > Atomic snapshots are what we'd like for dump too, since we desire
> > > accurate dumps (minimum drift), so its not a conflicting requirement.
> > > The difference is that while you could do i/o (e.g to flush pages
> > > to free up memory) before initiating an atomic snapshot, we can't.
> >
> > OTOH "best-effort-atomic" is probably okay for you, while it is not
> > acceptable for swsusp. Hopefully the code is not going to get too
> > complicated by "must be atomic" and "must work with crashed system"
> > requirements...
> >
> For the kind of atomicity you need there probably are two
> steps:
> 1) Quiesce the system - get to a point of consistency (when you
> can take a resumable snapshot)
> 2) Perform an atomic copy / snapshot
>
> Step (1) would be different for swsusp and crash dump (not
> intended to be common ). But for Step (2), do you think
> what you need/do is complicated by crashed system requirements ?
Well, I guess count_and_copy_data_pages() is easy to share, OTOH it is
really small piece of code. Also do you think you can free half of
memory in crashed system? Thats what swsusp currently does...
[I need really little about LKCD... But you are going to need modified
disk drivers etc, right? I'd like to get away without that in swsusp,
at least in 2.6.X.]
Pavel
-- Horseback riding is like software... ...vgf orggre jura vgf serr. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Feb 28 2003 - 22:00:48 EST