On Thu, Jul 10, 2014 at 08:45:08PM -0400, Eric Whitney wrote: > > Reverting the suspect patch - 007649375f - on 3.16-rc3 and running on the > Panda yielded 10 successive "successful" generic/068 failures (no block > bitmap trouble on reboot). So, it looks like that patch is all of it. Thanks again Eric, for finding this!! > Running the same test scenario on Darrick's patch (CONFIG_EXT4FS_DEBUG => > CONFIG_EXT4_DEBUG) applied to 3.16-rc3 lead to exactly the same result. > No panics, BUGS, or other misbehavior whether generic/068 completed > successfully or failed (and that test used here simply because it was > convenient) and no trouble on boot, etc. I've been looking more closely at the changes in line, and I suspect the real fix is that we should move these lines: ext4_free_blocks_count_set(sbi->s_es, EXT4_C2B(sbi, ext4_count_free_clusters(sb))); sbi->s_es->s_free_inodes_count =cpu_to_le32(ext4_count_free_inodes(sb)); after the journal is run. Not that it really matters since so very little (and nothing for normal file system operation, including the statfs(2) system call) actually depends on the free blocks count in the superblock --- instead we the percpu "s_freeclusters_count" and "s_dirtyclusters_counter" fields for scalability reasons --- but if we *are* going to set these fields in the on-disk superblock, we should wait until *after* we have updated the allocation bitmaps before we start counting the free blocks in those bitmaps. Cheers, - Ted -- 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
