On Sat, 21 Apr 2012, Tim Connors wrote:
On Sat, 21 Apr 2012, Craig Sanders wrote:
On Wed, Apr 11, 2012 at 11:08:41AM +1000, Tim Connors wrote:
As long as the file is either the new or the old version, and not zeroed out because of braindead filesystem behaviour,
you've made this claim a few times about XFS. sometimes naming XFS explicitly, and sometimes not as here.
i suspect it's because you don't know or don't understand how XFS works.
tl;dr version: XFS does not zero sectors due to brain-dead filesystem behaviour.
Not taking rename() as being an implicit barrier is braindead. ext4 fixed that. I don't believe XFS has for idealogical reasons. Instead of putting a small workaround that causes bugger-all impact on performance in kernel code, they insist that decades of userspace should change its behaviour instead.
Speaking of braindead filesystems, a few hours ago, I had a nasty power outage that my UPS didn't catch (batteries appear dead despite monitoring tell me they are all A-OK. But it has been 3 years). External disk hosting the backups lost power, but laptop remained alive. Disk was innactive at the time. That's ok, reattach drive, perform a dance with kill and mount, and restart the backup job. And then just moments ago, I got this in my kernel logs: Internal error xfs_btree_check_sblock at line 119 of file /home/blank/debian/kernel/release/linux-2.6/linux-2.6-3.2.4/debian/build/source_amd64_none/fs/xfs/xfs_btree.c Awesome! I hadn't yet gotten around to syncing the FS to my new ZFS installation on the NAS that also lost power but would probably cope with it better. But that's ok, I should be able to run fsck.xfs right? Who writes this shit? -- Tim Connors