On Wed, Oct 10, 2012 at 01:02:52PM -0400, Andrey Sidorov wrote: > On Tue, Oct 9, 2012 at 9:51 AM, Theodore Ts'o <tytso@xxxxxxx> wrote: > > > It is indeed, something we need to fix, and it's part of the problem > > where where the delayed allocation for bigalloc is completely screwed > > up. Part of the problem is when we write into a cluster which has not > > yet been mapped in the extent tree, but which might (or might not) > > have had other blocks in the cluster that have already been subject to > > delayed allocation, we don't know whether to reserve clusters for the > > purposes of doing the the delayed allocation accounting. Fixing this > > w/o the extent status tree means having to search the page cache and > > for other pages in the cluster, which is not only painful, but tricky > > from the perspective of lock ordering. > > > > Unfortunately, I didn't notice this problem originally because I > > hadn't been doing regular xfstests runs with bigalloc, and most of my > > testing had been with direct I/O, where these issues didn't come up. > > > > - Ted > > Hi Ted, > > Does it mean I'd better turn off delalloc if I use bigalloc with linux 3.5.3? Hi Andrey, This warning is only triggered in a stress test case. In our product system we never meet this warning, certainly we have backported bigalloc to 2.6.32 kernel, though. So IMHO we needn't turn off delalloc. Regards, Zheng -- 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
