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? Regards, Andrey. -- 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
