| |||||||||||||
XFS a good contender. On SGIs.XFS a good contender. On SGIs.Posted Jun 18, 2006 11:33 UTC (Sun) by nix (subscriber, #2304)In reply to: XFS a good contender. On SGIs. by dododge Parent article: Time for ext4?
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.)
(Log in to post comments)
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.
|
|||||||||||||