On Tue 30-09-14 23:01:08, Pavel Machek wrote: > > > On next boot to Debian stable, I got stacktrace, and messages about > > > ext4 corruption. Back to Debian testing. systemd ran fsck, determined > > It would be really good to get those messages... Ideally you could also > > use > > e2image -r <partition> | bzip2 -c > > to store fs metadata before doing anything else with the fs to a usb stick. > > That is invaluable for future analysis. > > Too late for that :-(. OK, you can take a note for next time ;) > > > it can't fix it, dropped me into emergency shell, _but mounted the > > > filesstem, anyway_. Oops. > > What kernel versions are you running in Debian testing and stable? > > Debian testing was 3.17-rc4, AFAICT. For debian stable -- not sure. OK, there were some changes to orphan list locking in 3.17-rc1. If I screwed up it could cause orphan list corruption. But for now I don't think that's the issue. > > My guess would be that kernel had problems only during orphan inode > > recovery (i.e. when deleting already deleted files) and we let the mount > > proceed if this fails because it's a relatively harmless problem. > > Is there some phase during shutdown where journalling no longer > protects fs integrity? No. We first finish all modifications to the fs and only after that clean up the journal. So that makes all changes to the fs protected. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- 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
