On Wed, Oct 16, 2013 at 4:10 PM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: > On 10/16/13 9:04 AM, Filipe David Borba Manana wrote: >> This test is motivated by an issue found by a btrfs user, addressed >> and described by the following GNU/Linux kernel patch: >> >> https://patchwork.kernel.org/patch/3046931/ > > Hi Filipe, thanks for the patch. > > Usually we don't want to add new, possibly-failing cases to old tests; > that makes it harder to identify when the code regressed vs. when > the test changed to test new things. > > It would be better to just copy the framework of tests/shared/051 > to a new test in shared/ and test only this new inheritance > problem. Ok, I wasn't aware of that logic, which makes sense. > > Also, I'm confused about this hunk: > >> @@ -345,7 +345,12 @@ chacl $acl2 largeaclfile >> getfacl --numeric largeaclfile | _filter_aces >> >> echo "1 above xfs acl max" >> -chacl $acl3 largeaclfile >> +if [ "$FSTYP" != "btrfs" ]; then >> + chacl $acl3 largeaclfile >> +else >> + echo 'chacl: cannot set access acl on "largeaclfile": Invalid argument' >> +fi >> + >> getfacl --numeric largeaclfile | _filter_aces >> >> echo "use 16 aces" > > What's that about? That chacl command succeeds on btrfs, which makes the test fail. Seems to rely on some xfs specific limit. By moving this test into a new file, that hack is no longer needed. Thanks Eric. > > Thanks, > -Eric > -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
