On Mon, Sep 16, 2013 at 11:44 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Thu, Sep 12, 2013 at 06:51:05PM -0500, Mark Tinguely wrote: >> The secret to tripping over the bug is run the test until fsstress >> fills the filesystem before removing the files. So an error >> handling? >> >> I use the test: >> >> #!/bin/sh >> >> ltp/fsstress -z -s 1378390208 -fsymlink=1 -n9999999 -p4 -d /test2 >> cd /test2 >> sync >> rm -rf * >> >> If your filesystem is smaller, decrease the -n to make the test faster. >> >> I have still not gotten a core, though Michael Semon sent one. > > It would be useful if we could wire this up for xfstests Just set it up accurately because it takes a long time. It takes a while to create the links. Additionally, fsstress will keep iterating after the FS is full, and all those extra iterations take time. In testing on x86, Brian's test will succeed in 10 GB but fail in 11 GB. I don't know if that is the case on x86_64 as well. After the failure case is met and the rm operation hits the assert, continued mount-and-rm operations will also cause the assert to fire, without needing to fill the FS with links again. I don't know when that "bonus condition" stops happening. xfs_repair makes matters worse, IIRC. That's about all I can add. Thanks! Michael _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
