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

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages