@Stefan #8, On our server which I first saw the crash on, only three out of the eight or so xfsdump backups regularly scheduled caused this crash. The others all backed up "successfully". The dump I originally started this case with actually produced a partial backup size. The other two backup jobs resulted in 0 length dump files. Thus I decided to focus on the backup job which resulted in some size at all.
I could boot from the -26 kernel build and get 100% success backing up. Reboot to the -27 kernel, xfsdump crashes. The crashing has persisted into the -28 kernel build. For now, -26 is where we must stay.
Getting no responses here, I referenced this bug report with a note to the XFS developer list. Shortly some xfs chances were identified as being done for the -27 kernel, that one was suspected as having gotten overlooked when xfs code changes were merged into the Ubuntu Lucid code.
The thread on the xfs developer list has fallen silent, and now progress has been made on this bug report.
@Stefan #8, On our server which I first saw the crash on, only three out of the eight or so xfsdump backups regularly scheduled caused this crash. The others all backed up "successfully". The dump I originally started this case with actually produced a partial backup size. The other two backup jobs resulted in 0 length dump files. Thus I decided to focus on the backup job which resulted in some size at all.
I could boot from the -26 kernel build and get 100% success backing up. Reboot to the -27 kernel, xfsdump crashes. The crashing has persisted into the -28 kernel build. For now, -26 is where we must stay.
Getting no responses here, I referenced this bug report with a note to the XFS developer list. Shortly some xfs chances were identified as being done for the -27 kernel, that one was suspected as having gotten overlooked when xfs code changes were merged into the Ubuntu Lucid code.
The thread on the xfs developer list has fallen silent, and now progress has been made on this bug report.