on crash xfs can loose/corrupt files, even after sync. what exactly occured: mount xfs with logbsize=256 (now i switched to defaults) work, copy files... run sync() or even sync() in a loop. crash (i'm crashing with bug 49191) reboot. you got a message: XFS (dm-0): Mounting Filesystem XFS (dm-0): Starting recovery (logdev: internal) XFS (dm-0): xlog_recover_process_data: bad clientid 0x0 XFS (dm-0): log mount/recovery failed: error 5 XFS (dm-0): log mount failed and some thing about can't find superblock (if i remember correctly) now, i make xfs_repair -L ... and mount again results: some files disappeared, others - have a garbade inside for the sample - notebooks.list was replaced with preferences.conf; preferences.conf itself have a mess of multiple times previous content of preferences.conf + some other files content. i want to say one more time, this mess occured after sync. some background about setup: sata hdd, xfs over dm-crypt. please, let me know if you need more information.
The log recovery problem (bad client ID) was found and fixed yesterday. Patch is here: http://oss.sgi.com/pipermail/xfs/2012-October/022155.html Your data corruption problems are a result of running xfs_repair -L, not because of the log recovery problem. sync has nothing to do with it - when you zero the log rather than recover it you are destroying metadata written to the log by sync required to make the filesystem consistent. xfs_repair tries to recover the mess as best it can, but xfs_repair does not recover data - it only makes the filesystem metadata consistent again. Hence your data corruption is a result of your actions in response to the log recovery bug, not caused by the problem. You are better off reporting problems to #xfs on freenode or xfs@oss.sgi.com than reporting them to this bugzilla - at least someone might be able to help you before you make a mistake.... -Dave.