[Top] [All Lists]

Re: TAKE 981498 - use KM_MAYFAIL in xfs_mountfs

To: "Eric Sandeen" <sandeen@xxxxxxxxxxx>, "Bhagi rathi" <jahnu77@xxxxxxxxx>, "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: Thu, 7 Aug 2008 22:53:55 +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=uvdD4/E6v59xphbXmHr7Hk4uU1tFe4JJVmqnHAFVKJE=; b=iOTH0vSzo9Exgt0V/KppxRgJsNHluyiaJLHKjPXzs5U1vT03SkRiQ1+F9LqupouNpP /bYposkzbfOArZKPh/NehlsKEpoNRqqDrJjhQj1dkPagn/bq8H1U/YExS1NzcQwaIK1/ cjQFBnOU7jbIb4ggPthJ8wu+0liELpwmRhBrg=
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=LrWlz3X0FkCJmtYqaS0pWTsKACwU/fHxt2j0LWHekiwNFiI2uPTpPxlosDKwXOQ/Zw dBjtYvekjN+VnNtrFULcnf41U6gPKEndhYOxEp0rQjefI5ybO75+XrIyvM8+osSTcWH0 13AMQSO+elvsXZRkIXnSy5IO+4WK7IOSMdix8=
In-reply-to: <20080806202256.GR21635@disturbed>
References: <20080806054121.CB2F258C52A4@xxxxxxxxxxxxxxxxxxxxxxx> <cc7060690808061022i1dce01dfx9e43ad3a75e5c936@xxxxxxxxxxxxxx> <489A01B0.5050606@xxxxxxxxxxx> <20080806202256.GR21635@disturbed>
Sender: xfs-bounce@xxxxxxxxxxx
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
 of XFS needing memory to clean dirty memory? That is of good priority
 to engineer than this handling of ENOMEM in transactions.


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

[[HTML alternate version deleted]]

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