On Fri 29-01-16 07:55:25, Dave Chinner wrote: > On Tue, Jan 26, 2016 at 10:50:23AM +0100, Michal Hocko wrote: [...] > > There have been patches posted during the year to fortify those places > > which cannot cope with allocation failures for ext[34] and testing > > has shown that ext* resp. xfs are quite ready to see NOFS allocation > > failures. > > The XFS situation is compeletely unchanged from last year, and the > fact that you say it handles NOFS allocation failures just fine > makes me seriously question your testing methodology. I am certainly open to suggestions there. My testing managed to identify some weaker points in ext[34] which led to RO remounts. __GFP_NOFAIL as the current band aid worked for them. I wasn't able to hit this with xfs. > In XFS, *any* memory allocation failure during a transaction will > either cause a panic through null point deference (because we don't > check for allocation failure in most cases) or a filesystem > shutdown (in the cases where we do check). If you haven't seen these > behaviours, then you haven't been failing memory allocations during > filesystem modifications. > > We need to fundamentally change error handling in transactions in > XFS to allow arbitrary memory allocation to fail. That is, we need > to implement a full transaction rollback capability so we can back > out changes made during the transaction before the error occurred. > That's a major amount of work, and I'm probably not going to do > anything on this in the next year as it's low priority because what > we have now works. I am quite confused now. I remember you were the one who complained about the silent nofail behavior of the allocator because that means you cannot implement an appropriate fallback strategy. Please also note that I am talking solely about GFP_NOFS allocation here. The allocator really cannot do much other than hoplessly retrying and relying on somebody _else_ to make a forward progress. That being said, I do understand that allowing GFP_NOFS allocation to fail is not an easy task and nothing to be done tomorrow or in few months, but I believe that a discussion with FS people about what can/should be done in order to make this happen is valuable. Thanks! -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
