On Thu, Nov 09, 2006 at 05:00:03PM +0100, Pavel Machek wrote: > > > > Well, it looks like the interactions with dm add quite a bit of > > > > complexity here. > > > > > > What about just fixing xfs (thou shall not write to disk when kernel > > > threads are frozen), and getting rid of blockdev freezing? > > > > Well, first I must admit you were absolutely right being suspicious with > > respect to this stuff. > > (OTOH your patch found real bugs in suspend.c, so...) > > > OTOH I have no idea _how_ we can tell xfs that the processes have been > > frozen. Should we introduce a global flag for that or something? > > I guess XFS should just do all the writes from process context, and > refuse any writing when its threads are frozen... I actually still > believe it is doing the right thing, because you can't really write to > disk from timer. As per the recent thread about this, XFS threads suspend correctly and XFS doesn't issue I/O from timers. The problem appears to be per-cpu workqueues that don't get suspended because suspend does not shut down workqueue threads. You haven't quiesced the filesystem, you haven't shut down work queues, but you're expecting the filesystem to magically stop using them when suspend starts up? You can't lay the blame on any subsystem for using an interface that suspend doesn't quiesce when you *haven't told the subsystem it should suspend itself*. This is true regardless of whether the subsystem is a device driver, part of the network stack or a filesystem. e.g. A struct device has suspend and resume callouts so that each device can be safely suspended and resumed. Suspend uses these and you sure as hell don't expect a device to work properly after a resume if you don't use these interfaces. So why do you think filesystems should be treated differently? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
