On Wed, Aug 16, 2017 at 04:31:01PM -0300, Ernesto A. Fernández wrote: > On Wed, Aug 16, 2017 at 11:35:02PM +1000, Dave Chinner wrote: > > On Wed, Aug 16, 2017 at 04:16:53AM -0300, Ernesto A. Fernández wrote: > > > On Wed, Aug 16, 2017 at 10:25:11AM +1000, Dave Chinner wrote: > > > > With that in mind, here's waht I suggested above: set the mode after > > > > the xattr. I haven't tested it - can you check it solves the problem > > > > case you are testing? > > > > > > It does. Of course the test still fails, as I said before, now claiming that > > > the filesystem is inconsistent. But that's a separate issue. > > > > It shouldn't be - what's the error that is being reported? > > xfs_repair, phase 3: > bad magic number febe in block 512 (14452) for directory inode 131 Hmmmm - that's a magic number for a non-crc DA node. Kinda implies that it ENOSPC'd in the middle of a tree split. Can you test on a CRC enabled filesystem and see if there are any other errors that are detected either at runtime or by repair? If it does fail, can youpost the full output of xfs_repair? > It seems to be caused by setting too many extended attributes to a > file. Yeah, > 500 blocks in the attribute tree implies at least several megabytes of xattrs on a file, which is something that pretty much never happens on production workloads. It's not likely to be a frequently exercised path... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
