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

Re: [dm-devel] Re: possible regression by the barrier patch in 2.6.30-rc2



Well let's go back to first principles.

There are two types of suspend.

(1) I don't care about the ordering of the I/O on the disk relative to
the suspend.  This one is easy: it's --noflush --nolockfs.

(2) I do want some control over the state of the device at the point
of the suspend.

Break this second case down.
If I have a filesystem, I require it to be consistent, so I require lockfs.

If the device belongs to a userspace database, I require it to be consistent,
so I must pause the database, at which point there is no further I/O being
issued to the device, then I suspend (and everything prior to this must be
flushed) and resume etc.  This can be either a "suspend with flush" OR the
flush could have been issued prior to the suspend (and any decent database
would have done that).

If I have any other application owning the device that cares about the
state on the device at the point of the suspend it *must* stop issuing
I/O while the suspend ioctl is run.  If any I/O continues to arrive
during the suspend, then that tells us we are necessarily in case (1).

So the implementation of 'suspend with flush' is simply 'issue a flush
using the standard mechanism for doing this and then issue a suspend'.
The 'suspend' itself does not need any special handling for 'flush'.
In practice, anything that requires a flush will issue it prior to
calling the suspend ioctl and not send I/O concurrently with the
suspend.  For backwards compatibility we could still support the
'suspend with flush' as I described - issue a flush internally before
entering the code that performs the suspend.

Alasdair


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