[lkml]   [2006]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2.6.19 5/5] fs: freeze_bdev with semaphore not mutex
    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

    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?


    Dave Chinner
    Principal Engineer
    SGI Australian Software Group
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-11-10 01:37    [W:0.027 / U:59.836 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site