On Tue, Apr 26, 2016 at 03:08:27PM -0700, Nikhilesh Reddy wrote: > As you know Android uses emergency remount instead of doing something like > "umount -a" in its shutdown/reboot path. No, I didn't know that. (And I wish I didn't. Yelch, what an ugly hack.) > Teh issue doesnt happen all the writer processes are killed before the > emergency remount Is there a missing "if", as in "if all the writer processes".... ? Note that an emergency remount is very much an emergency. So we don't do a graceful shutdown of any pending writes. (Normally we would return EBUSY if there anything that would prevent a clean remount.) In the emergency remount path, we bypass all of these checks. > And on disk we see that one of the files being written to has incorrect > ext4_inode->i_blocks_lo ( which is less than the the size of the file by > something like 2k) > > When unlinking this file the vfs inode->iblocks underflows and we end up > with EFBIG if EXT4_FEATURE_RO_COMPAT_HUGE_FILE is not enabled in the > superblock. > > Is this a known issue? No, this isn't a known issue. I've never seen anything like this, but all of the tests we do assume a forced poweroff, which we simulate using dm-flakey. We do *not* test the blunt-force-trauma which is inflected on the file system structures which results from doing an emergency remount. Off by 2k really doesn't make sense. I could see if it was off by 4k, but 2k is really wierd. > I would appreciate if you could point me in the right direction and any help > you can give me. Well, what I'd do is create a new ioctl interface which simulates an emergency ro on just the one device, and try to create a reliable repro. Eventually we'll want to add some tests for this in xfstests. - 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
