> >>>>> "Fermin" == Fermin Molina <fermin@xxxxxxxxxx> writes:
> Fermin> juno-tty1:~# mount /users Start mounting filesystem: md(9,0)
> Fermin> Starting XFS recovery on filesystem: md(9,0) (dev: 9/0) XFS:
> Fermin> xlog_recover_process_data: bad clientid XFS: log
> Fermin> mount/recovery failed XFS: log mount failed mount: wrong fs
> Fermin> type, bad option, bad superblock on /dev/md0,
> Fermin> or too many mounted file systems
> Hmmm. This may be caused by the recent BLKBSZSET changes. IIrc we
> had this problem before they went in.
> I'll run a few tests here and have a look.
This has been reported twice in the last couple of days from the cvs
kernel, one was after a clean unmount! Most of the log looks good,
but something in there is invalid, xfs_logprint gets confused as well
and core dumps or trips an assert.
Long term it would be nice if we could make log writes stripe aligned
which would probably also fix this (currently they are any old 512 byte
multiple long on any 512 byte boundary). However, it should work without
this. Try a default (small) log, zero it with xfs_repair, then mount,
do something, unmount. Repeat until it does not mount, look at the log
with xfs_logprint - there is a binary dump option which should not
fail. If there are zeros in the middle of the log then we have a problem
in the raid code.
> Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
> mkp@xxxxxxxxxxxxx, http://www.linuxcare.com/
> SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/