I think originally after I had started the machines (from power off) the filesystem on server1 (that later on could be repaired) was mounted but not accessible. If I tried to list the directory and l
Maybe the filesystem had encountered an error and shut down at this point. Anything in the logs? At that point you need to look for the specific failure message from the kernel, either dmesg or /var/
Jan 1 13:05:35 server1 kernel: XFS internal error XFS_WANT_CORRUPTED_RETURN at line 302 of file xfs_alloc.c. Caller 0xc4f027d0 (followed by an indecipherable call trace) I'm guessing that there was a
I searched the logs a little deeper. What I overlooked up to now is that close to the "XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1596 of file xfs_alloc.c" line. There are on both servers for
Here is the output of the commands you gave me above for the the corrupted filesystem that causes xfs_repair to segfault. The core dump of xfs_repair is available by http here: http://www.uni-koblenz
In between I contacted the vendor of the hardware IDE raids. The technician confirmed that these raids have a read/write cache and that there is *no* battery backup. So in case of an active filesyste
XFS gurus: If Rainer's raid system can not have the write cache enabled, is he getting any benefit from the XFS Journaling? I guess if it is an external array which does not have to have its power cy
If I had to hazard a guess, I'd think that the transaction log, being hit much more frequently than most other portions of the filesystem, would be much more aggressively cached by the hardware's alg
Am Mittwoch, 7. Januar 2004 16:42 schrieb Arthur Corliss: In between we found another possibility. Our vendor told us that now there is a firmware upgrade that allows the write cache to be disabled.
If you care much about performance, you will need to re-do any benchmarking or other performance testing after the change. I was testing our restore procedure recently for xfs filesystems. I found a