From: Dave Chinner <david@fromorbit.com>
To: Bhagi rathi <jahnu77@gmail.com>
Cc: Eric Sandeen <sandeen@sandeen.net>,
Lachlan McIlroy <lachlan@sgi.com>,
sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com
Subject: Re: TAKE 981498 - use KM_MAYFAIL in xfs_mountfs
Date: Fri, 8 Aug 2008 10:31:47 +1000 [thread overview]
Message-ID: <20080808003147.GA24344@disturbed> (raw)
In-Reply-To: <cc7060690808071023r6b29d6c0k9240eb677e78524e@mail.gmail.com>
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@fromorbit.com> 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.
> 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.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2008-08-08 0:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-06 5:41 TAKE 981498 - use KM_MAYFAIL in xfs_mountfs Lachlan McIlroy
2008-08-06 17:22 ` Bhagi rathi
2008-08-06 19:55 ` Eric Sandeen
2008-08-06 20:22 ` Dave Chinner
2008-08-07 17:23 ` Bhagi rathi
2008-08-08 0:31 ` Dave Chinner [this message]
2008-08-08 5:22 ` Bhagi rathi
2008-08-07 17:18 ` Bhagi rathi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080808003147.GA24344@disturbed \
--to=david@fromorbit.com \
--cc=jahnu77@gmail.com \
--cc=lachlan@sgi.com \
--cc=sandeen@sandeen.net \
--cc=sgi.bugs.xfs@engr.sgi.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox