Re: Oops while rebalancing, now unmountable.

[Shane Shrybman <shrybman@teksavvy.com>]

On Mon, 2010-11-15 at 13:46 -0500, Chris Mason wrote:
> Excerpts from Christoph Hellwig's message of 2010-11-15 13:23:14 -0500:
> > On Sun, Nov 14, 2010 at 11:12:22PM +0100, Andrea Arcangeli wrote:
> > > I just wrote above that it can happen upstream without THP. It's not
> > > THP related at all. THP is the consumer, this is a problem in migrate
> > > that will trigger as well with migrate_pages or all other possible
> > > migration APIs.
> > > 
> > > If more people would be using hugetlbfs they would have noticed
> > > without THP.
> > 
> > Okay, it seems THP is really just the messenger for bad VM practices
> > here.
> > 
> > > +static int btree_migratepage(struct address_space *mapping,
> > > +                       struct page *newpage, struct page *page)
> > > +{
> > > +       /*
> > > +        * we can't safely write a btree page from here,
> > > +        * we haven't done the locking hook
> > > +        */
> > > +       if (PageDirty(page))
> > > +               return -EAGAIN;
> > > 
> > > fallback_migrate_page would call writeout() which is apparently not
> > > ok in btrfs for locking issues leading to corruption.
> > 
> > Hmm, it seems the issue for that particular problem is indeedin btrfs.
> > If it needs external locking for writing out data it should not
> > implement ->writepage to start with.  Chris, can you explain what's
> > going on with the btree code? It's pretty funny both in the
> > btree_writepage which goes directly into extent_write_full_page
> > if PF_MEMALLOC is not set, but otherwise does much more complicated
> > work, and also in btree_writepages which skips various WB_SYNC_NONE,
> > including the very weird check for for_kupdate.
> 
> So, I had THP + a patched btrfs running all weekend and I can safely say
> I've fixed this one now. 
> 

That seems like good news!

Is that btrfs patch available somewhere?

Where does this leave the existing corrupted btrfs'?

Thanks guys,

Shane