[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[dm-devel] Re: [PATCH 2.6.19 5/5] fs: freeze_bdev with semaphore not mutex



On Fri 2006-11-17 12:40:51, David Chinner wrote:
> On Fri, Nov 17, 2006 at 12:40:53AM +0100, Pavel Machek wrote:
> > On Fri 2006-11-17 10:23:49, David Chinner wrote:
> > > On Sun, Nov 12, 2006 at 11:43:05PM +0100, Rafael J. Wysocki wrote:
> > > > On Sunday, 12 November 2006 23:30, David Chinner wrote:
> > > > > And how does freezing them at that point in time guarantee consistent
> > > > > filesystem state?
> > > > 
> > > > If the work queues are frozen, there won't be any fs-related activity _after_
> > > > we create the suspend image. 
> > > 
> > > fs-related activity before or after the suspend image is captured is
> > > not a problem - it's fs-related activity _during_ the suspend that
> > > is an issue here. If we have async I/O completing during the suspend
> > > image capture, we've got problems....
> > 
> > fs-related activity _after_ image is captured definitely is a problem
> > -- it breaks swsusp invariants.
> > 
> > During image capture, any fs-related activity is not possible, as we
> > are running interrupts disabled, DMA disabled.
> 
> Ok, so the I/o that finishes during the image capture won't be reported
> until after the capture completes. that means we lose the capability

There's no I/O in flight during image capture. Interrupts are
disabled, DMAs are stopped, and drivers were told to shut down (that
includes finishing any outstanding work, and drivers do that
currently; but perhaps docs should be more explicit about it).
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]