TAKE 981498 - use KM_MAYFAIL in xfs_mountfs

TAKE 981498 - use KM_MAYFAIL in xfs_mountfs

[Lachlan McIlroy]

use KM_MAYFAIL in xfs_mountfs

Use KM_MAYFAIL for the m_perag allocation, we can deal with the error
easily and blocking forever during mount is not a good idea either.


Signed-off-by: Christoph Hellwig <hch@lst.de>

Date:  Wed Aug  6 15:40:44 AEST 2008
Workarea:  redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-mm
Inspected by:  
hch
lachlan
Author:  lachlan

The following file(s) were checked into:
  longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb


Modid:  xfs-linux-melb:xfs-kern:31837a
fs/xfs/xfs_mount.c - 1.445 - changed
http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.445&r2=text&tr2=1.444&f=h
	- use KM_MAYFAIL in xfs_mountfs

Re: TAKE 981498 - use KM_MAYFAIL in xfs_mountfs

[Bhagi rathi]

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.

I am trying to understand why xfs_perag_t? Mount/Unmount
are not frequent activities, it is better for them to succeed
if operating system can allocate memory and take them
forward.

-Saradhi.

On Wed, Aug 6, 2008 at 11:11 AM, Lachlan McIlroy <lachlan@sgi.com> wrote:

> use KM_MAYFAIL in xfs_mountfs
>
> Use KM_MAYFAIL for the m_perag allocation, we can deal with the error
> easily and blocking forever during mount is not a good idea either.
>
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
>
> Date:  Wed Aug  6 15:40:44 AEST 2008
> Workarea:  redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-mm
> Inspected by:
> hch
> lachlan
> Author:  lachlan
>
> The following file(s) were checked into:
>  longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb
>
>
> Modid:  xfs-linux-melb:xfs-kern:31837a
> fs/xfs/xfs_mount.c - 1.445 - changed
http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/> xfs_mount.c.diff?r1=text&tr1=1.445&r2=text&tr2=1.444&f=h
>
> http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.445&r2=text&tr2=1.444&f=h
>        - use KM_MAYFAIL in xfs_mountfs
>
>
>
>
>


[[HTML alternate version deleted]]

Re: TAKE 981498 - use KM_MAYFAIL in xfs_mountfs

[Eric Sandeen]

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.
> 
> I am trying to understand why xfs_perag_t? Mount/Unmount
> are not frequent activities, it is better for them to succeed
> if operating system can allocate memory and take them
> forward.

But that's the big if, right?

If the system is so starved that you can't get this memory to even start
the mount process, I'm sure it's better to fail the mount with -ENOMEM
than to add to the current system memory stress.

In general KM_MAYFAIL sounds like a good plan when you can handle the
failure gracefully, I think.

-Eric

Re: TAKE 981498 - use KM_MAYFAIL in xfs_mountfs

[Dave Chinner]

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....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: TAKE 981498 - use KM_MAYFAIL in xfs_mountfs

[Bhagi rathi]

On Thu, Aug 7, 2008 at 1:25 AM, Eric Sandeen <sandeen@sandeen.net> 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.
> >
> > I am trying to understand why xfs_perag_t? Mount/Unmount
> > are not frequent activities, it is better for them to succeed
> > if operating system can allocate memory and take them
> > forward.
>
> But that's the big if, right?
>
> If the system is so starved that you can't get this memory to even start
> the mount process, I'm sure it's better to fail the mount with -ENOMEM
> than to add to the current system memory stress.


 Not really. It is going to fail many automated scripts.  We are designing
 for a problem that system  is starved with memory. It points to a bug
 in memory & system dirty state cleaning, they are the ideal problems
 to be solved this instead of this.  As long as system recovers, it is  good
 not to disturb automated scripts by introducing these kind of  unnecessary
 failures of the mount command.



>
>
> In general KM_MAYFAIL sounds like a good plan when you can handle the
> failure gracefully, I think.


 Not really. It fails mount gracefully, however, it needs administrative
action.
 It is expected that operating system will recover and functional without
 admin intervention.

Cheers,
Bhagi.

>
>
> -Eric
>


[[HTML alternate version deleted]]

Re: TAKE 981498 - use KM_MAYFAIL in xfs_mountfs

[Bhagi rathi]

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? That is of good priority
 to engineer than this handling of ENOMEM in transactions.


Cheers,
Bhagi.


>
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
>


[[HTML alternate version deleted]]

Re: TAKE 981498 - use KM_MAYFAIL in xfs_mountfs

[Dave Chinner]

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

Re: TAKE 981498 - use KM_MAYFAIL in xfs_mountfs

[Bhagi rathi]

On Fri, Aug 8, 2008 at 6:01 AM, Dave Chinner <david@fromorbit.com> 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@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.


 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@fromorbit.com
>


[[HTML alternate version deleted]]