Jumping into this mid-thread...
> >> Oct 27 09:19:12 smbserver kernel: xfs_force_shutdown(md(9,5),0x8)
> >> called from line 1039 of file xfs_trans.c. Return address =
> >> 0xe08ae312
> >> Oct 27 09:19:12 smbserver kernel: Corruption of in-memory data
> >> detected. Shutting down filesystem: md(9,5)
> >> Oct 27 09:19:12 smbserver kernel: Please umount the filesystem, and
> >> rectify the problem(s)
> >> Oct 27 10:36:44 smbserver kernel: PCI: Unable to handle 64-bit
> >> address space for
I think the PCI conflicts *might* be a red herring. Note the timestamps.
The xfs shutdown occured an hour before these PCI errors.
> >> Oct 27 10:36:44 smbserver kernel: PCI: Unable to handle 64-bit
> >> address space for
But out of curiosity, did you accidentally clip this line
cutting-and-pasting? "address space for"... what?
> >> Oct 27 10:36:44 smbserver kernel: Unknown bridge resource 2: assuming
> >> transparent
> >> Oct 27 10:36:44 smbserver kernel: PCI: Device 00:1f.1 not available
> >> because of resource collisions
Without knowing more about your hardware I'm not going to take a guess at
the root cause of these messages. PCI-PCI bridges generally "just work"
these days. Again, I don't see a direct corrolation between this and the
xfs_force_shutdown.
> conclusive. The XFS partitions would disappear from Samba shares. If I tried
An XFS shutdown means all I/O is stopped so it doesn't make itself worse.
Samba won't see it, and neither will anything else. So that much
follows. You'll probably need to shutdown Samba and whataver else is
_trying_ to access the filesystem before you can umount it. If you have
'lsof' on your system it can help track down what's holding it "busy."
Then xfs_check might be worth trying out.
Did I miss a message stating what kernel and XFS revision is involved?
--
#!/jameel/akari
sleep 4800;
make clean && make breakfast
|