On Tue, Jun 20, 2017 at 09:01:11AM -0400, David Shaw wrote: > On Jun 16, 2017, at 1:53 PM, Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: > > > > Hi all, > > > > So I /think/ the xfs_attr_inactive crashes that both of you have been > > seeing are a result of XFS assuming that there aren't ever any mapping > > holes in the extended attribute fork and crashing when it tries to > > grab a buffer for the hole and fails to notice that holes don't have > > buffers. This lightly tested patch gets rid of /that/ problem. > > > > So, if you're willing, can you try this out and see if the crashes go > > away? Granted, this might only enable us to lurch on whatever's next... > > I can give this a try. > > Now that you have an idea of what caused the issue, is there some way > to (easily or not) reproduce it, ideally in userspace? Part of the > problem we're having is that we can't reproduce it on a test machine > so are forced to wait for it to happen in the field under load, where > it inconveniences users. I know what caused the crash, but I don't know what caused the hole in the xattr fork that caused the crash. It would appear that the xattr hash tree contains a pointer to an xattr fork offset that is no longer mapped, but I don't know how we end up with a dangling pointer -- whether this is corruption going on in the attribute fork, or merely a bug in the routine that tears down the attribute fork and accidentally tries to delete something twice. Unfortunately, the metadumps you've both sent me don't seem to contain any inodes with sparse attribute forks, so evidently something cleaned up the filesystem before the metadump was taken. It might help to know a little more about what's going on with the xattrs that are being attached to those files. A fair number of the inodes seem to have extended attributes with 2k values attached. Does your workload involve adding and deleting a large number of xattrs? A number of large xattrs? A large number of large xattrs? That said, if we're tearing down the inode anyway, maybe it doesn't matter if there's a hole in the map, seeing as the attr_inactive function already knows how to handle holes and the blocks are all getting freed anyway. --D > > David > -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
