On 11/18/10 12:04 PM, Eric Sandeen wrote: > On 11/18/10 11:10 AM, Andrew Morton wrote: >> On Thu, 18 Nov 2010 08:55:18 -0600 Eric Sandeen <sandeen@xxxxxxxxxx> wrote: >> >>>> Can we just delete writeback_inodes_sb_nr_if_idle() and >>>> writeback_inodes_sb_if_idle()? The changelog for 17bd55d037a02 is >>>> pretty handwavy - do we know that deleting these things would make a >>>> jot of difference? >>> >>> Really? I thought it was pretty decent ;) >>> >>> Anyway, xfstests 204, "Test out ENOSPC flushing on small filesystems." >>> shows the problem clearly, IIRC. I should have included that in the >>> changelog, I suppose, sorry. >> >> Your email didn't really impart any information :( >> >> I suppose I could accidentally delete those nasty little functions in a >> drivers/parport patch then wait and see if anyone notices. >> > > Um, ok, then, to answer the question directly : > > No, please don't delete those functions, it will break ENOSPC handling > in ext4 as shown by xfstests regression test #204 ... Further - What is going on here is that with delayed allocation, ext4 takes reservations against free blocks based on the data blocks it must write out, and the worst-case metadata that the writeout may take. Getting writeback failing with ENOSPC would be bad. But then we wind up with a bunch of unflushed writes sitting on huge metadata reservations, and start hitting ENOSPC due to that worst-case reservation. After a sync we have tons of free space again, because the worst-case space reservations turned into usually best-case reality. That's what the function is used for; once we start filling up the fs, we proactively flush data to free up the worst-case metadata reservations. Dropping it will put us back in the bad situation. If there are other ideas to fix it, I'm all ears, but this worked. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
