xfs
[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
fall-out
 of XFS needing memory to clean dirty memory? That is of good priority
 to engineer than this handling of ENOMEM in transactions.


Cheers,
Bhagi.


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


[[HTML alternate version deleted]]


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