Hi! > > > This means, however, that we can leave the patch as is (well, with the minor > > > fix I have already posted), for now, because it doesn't make things worse a > > > bit, but: > > > (a) it prevents xfs from being corrupted and > > > > I'd really prefer it to be fixed by 'freezeable workqueues'. > > I'd prefer that you just freeze the filesystem and let the > filesystem do things correctly. Well, I'd prefer filesystems not to know about suspend, and current "freeze the filesystem" does not really nest properly. > > Can you > > point me into sources -- which xfs workqueues are problematic? > > AFAIK, its the I/O completion workqueues that are causing problems. > (fs/xfs/linux-2.6/xfs_buf.c) However, thinking about it, I'm not > sure that the work queues being left unfrozen is the real problem. > > i.e. after a sync there's still I/O outstanding (e.g. metadata in > the log but not on disk), and because the kernel threads are frozen > some time after the sync, we could have issued this delayed write > metadata to disk after the sync. With XFS, we can have a of queue of That's okay, snapshot is atomic. As long as data are safely in the journal, we should be okay. > However, even if you stop the workqueue processing, you're still > going to have to wait for all I/O completion to occur before > snapshotting memory because having any I/O complete changes memory > state. Hence I fail to see how freezing the workqueues really helps > at all here.... It is okay to change memory state, just on disk state may not change after atomic snapshot. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
