a happy new year to everyone on this list ... well for some of my xfs filesystems the year had a bad start. Due to a powerfail on some systems that possibly rebootet and later again crashed due to a
What was the failure when you first tried to mount? Unable to find a superblock immediately after repair? I have never seen this before, sounds very odd. BTW running repair twice in sucession will ke
Do you have write-caching disabled in your drives/raid controller. IIRC, XFS requires that it be disabled to ensure the transaction log works as advertised. This definately impacts speed, but ... Gre
Some of the higher-end cards have battery backup for fast-write cache. You shouldn't have to disable it for those units. --Arthur Corliss Bolverk's Lair -- http://arthur.corlissfamily.org/ Digital Ma
Am Montag, 5. Januar 2004 16:35 schrieben Sie: The basis for storage are IFT 7250 Raids with IDE disks inside (external its running fibrechannel). The device is configures as raid level 5. I looked i
If this still happens, It might be useful to see how much was overwritten, and if you recognise the data. You can use xfs_db to read and print the superblock. xfs_db -r /dev/diskxyz sb 0 print - a fo
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