see http://www.spinics.net/lists/linux-ext4/msg33716.html & http://www.spinics.net/lists/linux-ext4/msg33717.html mga1 & mga2 too... this caused for some mariadb data corruption on power loss, due to some change not being synced to disk (ie: the crash handler thinks it's synced, but it isn't...)
Priority: Normal => release_blockerCC: (none) => tmbWhiteboard: (none) => MGA1TOO MGA2TOO
That could explain why I recently lost my .bash_history on reboot
CC: (none) => thierry.vignaudAssignee: bugsquad => tmb
maybe not, because this one appears to be a corner case, ie: when the inode (size) has changed, but not the blocks. (iiuc) for mariadb, it meant that the recovery crash handler has thought that a certain block was synced, while it wasn't, and thus recovered it wrongly, making it corrupt...
is this bug still valid with last kernel ? (kernel 3.4 for mga2, kernel 3.6 for cauldron)
Keywords: (none) => NEEDINFO
well, since then, i've seen some more reports of ext4 fsync/fdatasync bugs... it would be nice to know what is going on now (Thomas will likely know)
Cauldron is ok. mga2: ext3 bug squashed in 3.4.11, ext4 one in 3.4.14. 3.4.20 will be pushed to QA as soon as it is released.
ok thanks so need anymore of this one specific one.
Keywords: NEEDINFO => (none)Status: NEW => RESOLVEDResolution: (none) => FIXED