xfs
[Top] [All Lists]

Re: TAKE 981498 - use KM_MAYFAIL in xfs_mountfs

To: "Bhagi rathi" <jahnu77@xxxxxxxxx>, "Eric Sandeen" <sandeen@xxxxxxxxxxx>, "Lachlan McIlroy" <lachlan@xxxxxxx>, sgi.bugs.xfs@xxxxxxxxxxxx, xfs@xxxxxxxxxxx
Subject: Re: TAKE 981498 - use KM_MAYFAIL in xfs_mountfs
From: "Bhagi rathi" <jahnu77@xxxxxxxxx>
Date: Fri, 8 Aug 2008 10:52:50 +0530
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=9AyXsxYkVeKTsS5V32yoUzvKx9jm4q1s9ujgdDh2Y+M=; b=Hjrzy/60jU5DBAFAd4vDB+tg6dlvfo3jzPtNaukg6vuieNTHwyavgI6h4pnRBSGPF3 GBfvpx1Gpu6itI6RHdKTnzsMNxsspQemCQTsAQwVgEqVwVm1LmKqjrQBcTfkfRi0InGw OkmVP//hjIKydlJ94NAk5vIr86rJys4Tg8/Ys=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=HyvTcxE4pI4/JWEWEEPP/OgEZaeMdhgy3AHPHxyf9BUY0SMH4buPdTZFkfRBHE47ef UweV18GiWdIw+FM8KpDPTl/p9lkLuL2Y745HQS5LV3trmCfbRJvg5FvPJzgaX/CrZomI zuSfLcCXPXD10jR+Y38RGp5AuyAEmmBg8NOIQ=
In-reply-to: <20080808003147.GA24344@disturbed>
References: <20080806054121.CB2F258C52A4@xxxxxxxxxxxxxxxxxxxxxxx> <cc7060690808061022i1dce01dfx9e43ad3a75e5c936@xxxxxxxxxxxxxx> <489A01B0.5050606@xxxxxxxxxxx> <20080806202256.GR21635@disturbed> <cc7060690808071023r6b29d6c0k9240eb677e78524e@xxxxxxxxxxxxxx> <20080808003147.GA24344@disturbed>
Sender: xfs-bounce@xxxxxxxxxxx
On Fri, Aug 8, 2008 at 6:01 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:

> On Thu, Aug 07, 2008 at 10:53:55PM +0530, Bhagi rathi wrote:
> > On Thu, Aug 7, 2008 at 1:52 AM, Dave Chinner <david@xxxxxxxxxxxxx>
> wrote:
> >
> > > On Wed, Aug 06, 2008 at 02:55:28PM -0500, Eric Sandeen wrote:
> > > > Bhagi rathi wrote:
> > > > > Why are we going to block for ever? Mounting a file-system
> > > > > requires in-core log space buffers, reading of other buffers
> > > > > which needs allocation of memory greater than per ag
> > > > > structures.
> > > .....
> > > > In general KM_MAYFAIL sounds like a good plan when you can handle the
> > > > failure gracefully, I think.
> > >
> > > Yes, and that is the long term plan - to remove all KM_SLEEP
> > > allocations from XFS and allow them to fail gracefully. There's
> > > lots of work needed before we get there, though. e.g.
> > > right now we cannot survive an ENOMEM error in a transaction....
> >
> >
> >  I am not sure that we are solving right problem. Isn't the above is
> > fall-out
> >  of XFS needing memory to clean dirty memory?
>
> We can't avoid that. It is inherent in the design of XFS.  And the
> amount of memory is not easily bounded so existing solutions like
> wrapping slabs in mempools don't work, either.


 Interesting. The only dirty items are xfs inodes,  quota's and
 meta-data buffers.  We can fixed number of these items and
 ensure pushing of data  one after the other in the case of crunch.

 What are the objects of dirty data where the memory is not bounded?


>
> >  That is of good priority
> >  to engineer than this handling of ENOMEM in transactions.
>
> That's just one example of an extremely non-trivial piece of work
> that needs to be done to allow all memory allocations to fail.
> This work will be done for other reasons (like transaction
> rollback to prevent shutdowns on errors inside a dirty
> transaction), not specifically to allow memory allocations
> to fail.


Yes. I agree.

-Saradhi.


>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx
>


[[HTML alternate version deleted]]


<Prev in Thread] Current Thread [Next in Thread>