On Sat, Mar 24, 2012 at 02:11:28AM +1100, Anthony Shipman wrote:
I've been running a Centos 6.2 system for two months now. I've been using XFS for the /home file system since I had the impression it would be better for large file systems by avoiding long fsck times. At the same time the nvidia driver has proved to be buggy and has crashed the system several times.
more details required... please show output of lspci, and 'lspci -v' for you nvidia card. what brand/model card is it? does your BIOS have IOMMU support enabled? (i've found that that can cause problems for the nvidia driver) also details on your kernel version and hardware would be useful, including details your motherboard, disk controller, on the drives used by your XFS fs. also is XFS on raw disk partition(s) or LVM?
XFS has the habit of zeroing out some files each time there is a crash. This would be understandable for files that were being written around the time of the crash. But I've had files be erased that were created hours before the crash and were read-only after creation.
this zero-ing issue has got to be one of the most annoyingly common misconceptions about XFS. http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files_... Q: Why do I see binary NULLS in some files after recovery when I unplugged the power? Update: This issue has been addressed with a CVS fix on the 29th March 2007 and merged into mainline on 8th May 2007 for 2.6.22-rc1. XFS journals metadata updates, not data updates. After a crash you are supposed to get a consistent filesystem which looks like the state sometime shortly before the crash, NOT what the in memory image looked like the instant before the crash. Since XFS does not write data out immediately unless you tell it to with fsync, an O_SYNC or O_DIRECT open (the same is true of other filesystems), you are looking at an inode which was flushed out, but whose data was not. Typically you'll find that the inode is not taking any space since all it has is a size but no extents allocated (try examining the file with the xfs_bmap(8) command). BTW, the reason why you see NUL bytes in unflushed sectors after a crash is to avoid leaking data from whatever those sectors were used for before. e.g. say those sectors used to hold the data from /etc/shadow, or a script or config file containing passwords, or some other privacy/security-sensitive data....you wouldn't want that data exposed in, say, a user-owned file after a crash. after a crash, those sectors may contain some or all of the data you wanted/expected it to, some or all of the data from any previous use, or (most likely) some combination of both. either way, you can't trust that the data is good.
I expect I'll just switch to ext4.
ext4 is fine and, unlike xfs, will provide an easy upgrade path to btrfs when it's stable (or if you want to experiment). BTW, for most purposes, btrfs is stable enough. wouldn't trust a production server to it yet, but home use ought to be OK, esp if you make backups. craig -- craig sanders <cas@taz.net.au> BOFH excuse #252: Our ISP is having {switching,routing,SMDS,frame relay} problems