Thanks for the answer
>>>>> On Tue, 13 Apr 2010 10:58:22 -0400 (EDT)
>>>>> "RB" == Robert Brockway <robert@xxxxxxxxxxxxxxxxx> wrote:
RB> On Tue, 13 Apr 2010, Bernhard Gschaider wrote:
>>> xfs_db -r /dev/mapper/VolGroup00-LogVol04
>> xfs_db: unexpected XFS SB magic number 0x00000000 xfs_db: read
>> failed: Invalid argument xfs_db: data size check failed
>> cache_node_purge: refcount was 1, not zero (node=0x2a25c20)
>> xfs_db: cannot read root inode (22)
RB> Hi Bernhard. Hmm that doesn't sound good.
http://oss.sgi.com/archives/xfs/2007-04/msg00580.html suggests a sync
for that kind of situation. Any thoughts on this? I know that there is
no definite answer to his. Only guesses by people who have more
experience than me
>> The file-system is still mounted and working and I don't dare
>> to do anything about it (am in a mild state of panic) because I
>> think it might not come back if I do.
RB> I think your choice to sit back and evaluate your options
RB> before acting is a wise one, especially since the filesystem
RB> is apparently mounted and functioning.
RB> Depending on how worried you are there are various options
RB> available. Eg you could declare an emergency on the server
RB> and use xfs_freeze to freeze the filesystem while you take a
RB> backup. Note - I have never used xfs_freeze like this, it is
RB> just a suggestion. Naturally this will cause an outage and
RB> problems for users.
They'll have to live with that
RB> Alternatively you could use xfsdump to capture an incremental
RB> or full backup on the running system. (depending on whether
RB> you already have a level 0 xfs dump file or not). The
RB> developers have confirmed (on this list) that xfsdump will
RB> provide a consistent backup on a live filesystem.
RB> Please note that any heavy I/O (like a backup) has the
RB> potential to cause problems on a sick filesystem. In my
RB> experience xfs is inclined to automatically remount read-only
RB> if it detects problems. While this can be catastrophic for
RB> running processes it is helpful in protecting data so I'm
RB> happy it works this way.
RB> One last note. I hope you have good backups already. If you
RB> don't then this is the time to start taking good backups.
I have weekly backups with amanda. The tapes verify OK, but I never
tried a full-scale recover before.
RB> These are the notes from my backup talk:
>> I swear to god: I did not do anything else with the
>> xfs_*-commands than the stuff mentioned above
RB> I defrag XFS filesystems from cron as recommended by SGI and
RB> I've never had a problem. Maybe defragmentation didn't cause
RB> the problem - maybe it just revealed an underlying problem.
But it doesn't have to do with the hole that the xfs_bmap reported for