| |||||||||||||
XFS a good contender.XFS a good contender.Posted Jun 15, 2006 7:55 UTC (Thu) by migpc (guest, #24484)Parent article: Time for ext4?
Wouldn't XFS be a good contender to the Linux Filesystem Throne?
It's been for really long in the main kernel.
The question shouldn't be why? but why not?.
To me the 9 exabyte limit sounds pretty impressive.
Why rebuilding the wheel when we already have better wheels to use?
M*
(Log in to post comments)
XFS a good contender. Posted Jun 15, 2006 11:24 UTC (Thu) by nix (subscriber, #2304) [Link] Well, XFS is really complicated and its code is really rather ugly, with abstraction layers to make the Linux in-memory inode look like the traditional Unix in-memory inode (for ease of merging with IRIX) and other things which are normally not permitted in Linux at all.
So, no, I don't think that'll happen.
XFS a good contender. Posted Jun 15, 2006 14:46 UTC (Thu) by HenrikH (guest, #31152) [Link] And of course there is no way that the XFS code can be cleaned up ;). Especially now since SGI is bust so there is no more IRIX.
XFS a good contender. On SGIs. Posted Jun 15, 2006 18:20 UTC (Thu) by rfunk (subscriber, #4054) [Link] I used to be a big XFS fan.Then I discovered how easy it can be to lose a filesystem when the disk loses power or connectivity at the wrong time. Apparently SGI hardware works a bit differently from PC hardware, and XFS was built assuming the SGI hardware behavior. Now this was on a firewire-connected disk, so I didn't run out to re-mkfs my servers, but later when I was redoing the filesystems on one server anyway, I changed it to ext3.
XFS a good contender. On SGIs. Posted Jun 16, 2006 14:58 UTC (Fri) by sbergman27 (guest, #10767) [Link] 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.
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.
Or JFS? Posted Jun 16, 2006 7:41 UTC (Fri) by eru (subscriber, #2753) [Link] Also has been in the kernel for a while, has better performance than ext3, and is backed by a Linux-friendly company likely to be around for awhile (unlike SGI).Any downsides?
Or JFS? Posted Jun 17, 2006 1:40 UTC (Sat) by hchristeller (guest, #4246) [Link] JFS filesystems can expand, but not shrink. XFS has the same issue. This has made upgrading my MythTV system more complicated than it might have been. You can shrink ext3.
Other than that, I've been very pleased with JFS and how it handles the huge files created when recording HDTV. Adding a new disk with LVM and expanding the JFS filesystem was quick and easy.
|
|||||||||||||