| To: | Bhagi rathi <jahnu77@xxxxxxxxx> |
|---|---|
| Subject: | Re: TAKE 981498 - use KM_MAYFAIL in xfs_mountfs |
| From: | Eric Sandeen <sandeen@xxxxxxxxxxx> |
| Date: | Wed, 06 Aug 2008 14:55:28 -0500 |
| Cc: | Lachlan McIlroy <lachlan@xxxxxxx>, sgi.bugs.xfs@xxxxxxxxxxxx, xfs@xxxxxxxxxxx |
| In-reply-to: | <cc7060690808061022i1dce01dfx9e43ad3a75e5c936@mail.gmail.com> |
| References: | <20080806054121.CB2F258C52A4@chook.melbourne.sgi.com> <cc7060690808061022i1dce01dfx9e43ad3a75e5c936@mail.gmail.com> |
| Sender: | xfs-bounce@xxxxxxxxxxx |
| User-agent: | Thunderbird 2.0.0.14 (X11/20080501) |
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 |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: TAKE 981498 - use KM_MAYFAIL in xfs_mountfs, Bhagi rathi |
|---|---|
| Next by Date: | Re: TAKE 981498 - Use KM_NOFS for debug trace buffers, Eric Sandeen |
| Previous by Thread: | Re: TAKE 981498 - use KM_MAYFAIL in xfs_mountfs, Bhagi rathi |
| Next by Thread: | Re: TAKE 981498 - use KM_MAYFAIL in xfs_mountfs, Dave Chinner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |