On Jan 12, 2014, at 10:47 AM, Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx> wrote:
> If this is due to a bug it may have already been fixed. Note the first
> two things asked for.
Thanks for the pointer.
My kernels a bit old, but xfsprogs is shiny and new:
Linux vera 126.96.36.199 #1 SMP Fri Sep 30 23:55:41 PDT 2011 x86_64 x86_64 x86_64
xfs_repair version 3.1.11
2x4 core CPUs
8 GB RAM, mostly free (more than 6 GB cached)
/dev/lvmsas/tv /mnt/media/TV xfs
254 31 16252928000 dm-31
Which is a no-frills LVM2 volume allocation over mdadm raid-6.
meta-data=/dev/lvmsas/tv isize=256 agcount=33, agsize=126975872 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=4063232000, imaxpct=5
= sunit=128 swidth=512 blks
naming =version 2 bsize=4096 ascii-ci=1
log =internal bsize=4096 blocks=521728, version=2
= sectsz=512 sunit=8 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
Attempts to access the now-busted files/directories with accents in their paths
result in a kernel log like:
Jan 11 02:05:39 vera XFS (dm-31): I/O error occurred: meta-data dev dm-31 block
0x3c8ff73e0 ("xfs_trans_read_buf") error 11 buf count 4096
Original failure never hit the persistent log so I don’t have that; the system
would not shutdown cleanly and I kill it after several errors like:
Filesystem "dm-31": xfs_log_force: error 5 returned.
It claimed to be unmounted at that point (it didn’t show up in /proc/mounts)
but the related [xfsbufd/dm-31] process was still running and could not be
Description: S/MIME cryptographic signature