| |||||||||||||
XFS a good contender. On SGIs.XFS a good contender. On SGIs.Posted Jun 16, 2006 14:58 UTC (Fri) by sbergman27 (guest, #10767)In reply to: XFS a good contender. On SGIs. by rfunk Parent article: Time for ext4?
I believe this if only pertinent to the 1.0.x versions. It was fixed in the 1.1 version, released over four years ago.
That said, ext3 in its default data=order mode, and also in its data=journal mode, makes stonger guarantees about the consistency of the data after an unplanned shutdown. Of the Linux journalled filesystems, I believe that only ext3 and reiserfs even give you the option of these higher levels of guarantee.
But I believe that XFS is currently no worse than any other metadata only journalling filesystem out there, which means most of them.
(Log in to post comments)
XFS a good contender. On SGIs. Posted Jun 16, 2006 15:23 UTC (Fri) by rfunk (subscriber, #4054) [Link] Considering that my XFS problem happened with a 2.6 kernel, I don't thinkXFS 1.1 quite solved it all.
XFS a good contender. On SGIs. Posted Jun 17, 2006 0:57 UTC (Sat) by dododge (subscriber, #2870) [Link] The file-destruction problem certainly still exists: http://oss.sgi.com/projects/xfs/faq.html#nullsIt can make some types of debugging very painful. For example about a month ago my Xubuntu dapper system (using XFS) was having trouble getting X running on multiple video cards, and the failure mode of X was a hard-lock of the machine requiring a power-cycle. The use of XFS pretty much guaranteed that after reboot, Xorg.0.log was useless for debugging the problem. In at least one case it also null-filled the xorg.conf file that I was using for testing. I quickly got in the habit of typing "sync" a few times before doing anything even remotely risky, in hopes of protecting at least files that I wasn't actively working on. I don't know what's worse -- the fact that it fills the file with null bytes, or the fact that it leaves the metadata intact so that the file looks fine if you just do an "ls". A similar experience with Reiser4 resulted in xorg.conf disappearing entirely after a hard reboot, and perhaps that was a better way to fail since it was at least obvious that there was a problem. That said, I'm still using XFS.
XFS a good contender. On SGIs. Posted Jun 18, 2006 11:33 UTC (Sun) by nix (subscriber, #2304) [Link] I think it likely that the maintainer of GNU tar is using xfs. (Why? Because tar-1.15.90/src/extract.c contains nothing but null bytes, that's why.)
XFS a good contender. On SGIs. Posted Jun 19, 2006 17:00 UTC (Mon) by dododge (subscriber, #2870) [Link] Strange. extract.c seems to be fine in tar-1.15.90.tar.bz2 and tar-1.15.91.tar.bz2 from alpha.gnu.org.
XFS a good contender. On SGIs. Posted Jun 23, 2006 20:08 UTC (Fri) by nix (subscriber, #2304) [Link] Hm, maybe *I* had disk corruption. (On two separate machines, with RAID arrays? Strange.)
XFS a good contender. On SGIs. Posted Jun 23, 2006 22:15 UTC (Fri) by dododge (subscriber, #2870) [Link] I only checked the two tarfiles from one archive, so it's possible a copy somewhere is corrupt. (On two separate machines, with RAID arrays? Strange.) That it would happen the same way in two different filesystems is certainly unlikely. Aside: it's a bit surprising how common RAID failures can be. At a LUG discussion a few weeks ago someone mentioned that their RAID-5 was destroyed when, while synchronizing to repair a lost drive, a second drive died in the array. Several people (incuding myself) immediately jumped into the discussion with similar stories.
XFS a good contender. On SGIs. Posted Jul 3, 2006 23:12 UTC (Mon) by nix (subscriber, #2304) [Link] Yes; before 2.6.15, the md driver in the kernel had no way to test arrays for read-correctness without doing a massive dd by hand or a reconstruction, and no recourse when a bad block was found but to kick the drive (bad news if reconstructing).
Neither of these are true any longer, thanks be to Neil Brown :) you're only in trouble now if you have *the same* block unreadable on enough drives.
|
|||||||||||||