On Jan 12, 2014, at 10:47 AM, Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx> wrote: > http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F > > 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 2.6.39.2 #1 SMP Fri Sep 30 23:55:41 PDT 2011 x86_64 x86_64 x86_64 GNU/Linux xfs_repair version 3.1.11 2x4 core CPUs 8 GB RAM, mostly free (more than 6 GB cached) Related mount: /dev/lvmsas/tv /mnt/media/TV xfs rw,nosuid,nodev,noexec,relatime,attr2,delaylog,inode64,sunit=1024,swidth=4096,noquota 0 0 Underlying partition: 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 killed. Zach
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
