On Wed, 2002-05-01 at 11:15, Ravi Wijayaratne wrote:
> Hi All,
> We had a situation where XFS persistent logs were
> damaged irreparably due to hot swapping of disks. The
> damage to the logs are expected. However when trying
> to recover from the process XFS oopsed. The ksymoops
> attached at the end of the email.
> After having examined the code we discovered that the
> kernel is trying to access a NULL value in
> xlog_rec_header_t rhead->h_cycle_data
> in function xlog_unpack_data(). A simple fix as
> log->l_flags |= ( XLOG_DISK_LOG_CORRUPTED |
> and checking for XLOG_DISK_LOG_CORRUPTED in
> xlog_do_recovery_pass and returning EFSCORRUPTED
> caused mount to exit complaining about the file system
> However the question is what caused
> rhead->h_cycle_data to have a NULL value ?
> In xlog_do_recovery_pass() we notice that
> rhead->h_magicno is compared to XLOG_HEADER_MAGIC_NUM
> in several places. However EFSCORRUPTED is returned
> only for the case where (!(tail_blk <= head_blk)) and
> in other cases is simply ASSERTED but ignored. For the
> case where it oopsed there was a magic number
> Is this a possible oversight ?
It does look that way.
I suspect you need to run xfs_repair -L on this filesystem to ignore the
log and rebuild the rest of the fs.
> I am an XFS newbie and am greatly impaired by not
> being able to access the XFS design docs in oss.
> Anybody know where I could get them ?
Seth answered this, we are working on getting oss sorted out
again - some web site config was lost.
> Thank you
Steve Lord voice: +1-651-683-3511
Principal Engineer, Filesystem Software email: lord@xxxxxxx