On Wednesday, 15 November 2006 20:56, Rafael J. Wysocki wrote: > Hi, > > On Wednesday, 15 November 2006 19:50, Pavel Machek wrote: > > 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. > > There's one more thing, actually. If the on-disk data and metadata are > changed _after_ the sync we do and _before_ we create the snapshot image, > and the subsequent resume fails, Well, but this is equivalent to a power failure immediately after the sync, so there _must_ be a way to recover the filesystem from that, no? I think I'll prepare a patch for freezing the work queues and we'll see what to do next. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
