https://bugzilla.novell.com/show_bug.cgi?id=880599 https://bugzilla.novell.com/show_bug.cgi?id=880599#c6 James Carter <jimc@math.ucla.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|jimc@math.ucla.edu | --- Comment #6 from James Carter <jimc@math.ucla.edu> 2014-06-09 20:11:16 UTC --- Sorry to be slow testing the patched kernel, but we had to respond to CVE-2014-0224, and then the issues came up described in bug 881912, which may or may not be related to this one. The production and test servers are set up as i686 (vs. x86_64). I installed the patched iernel (kernel-default-3.11.10-0.x86_64.rpm) on a x86_64 test machine and got different results, plus I re-did my tests on the i686 server and got similar but not identical results. By the way, I'm not concerned if the user succeeds in writing significantly beyond his quota, but it seems like a useful piece of data for analysing the problem, so I report it when it happens. I'm still using "dd if=/dev/zero of=$dir/oinkage.dat bs=1M", executing on the client as the user (mathtest), to try to set off the bug(s). In this table, Kernel = what the server uses (11-0 = Jack's test kernel, 11-10 = distro's updated standard kernel), and NFSv = the NFS version that the client is using. For the first 8 tests, both the servers and the clients were x86_64. For the last 2 the server was i686, clients were x86_64. Kernel NFSv Fsys Outcome 10-0 4 ext4 EDQUOT (good), cut at 750Mb, very little overage 10-11 4 ext4 No signal (bad), had to kill writer 10-0 3 ext4 EDQUOT (good), "quota -v -l mathtest" claims to be using 750000 blocks, but the file is 1180467200 bytes or 1.18Gb. After I ran quotacheck, says 750004 blocks. 10-11 3 ext4 EDQUOT (good), "quota -v -l mathtest" claims to be using 750000 blocks, but the file is 888827904 bytes or 889Mb. After quotacheck, still says 750000 blocks. 10-0 3 ext3 EDQUOT (good), cut off at 1.4Gb, quota says 750Mb 10-11 3 ext3 EDQUOT (good), cut off at 750Mb, very little over Repetitions: ***** 5 all the same exc. overage 10-0 4 ext3 EDQUOT (good), cut off at 750Mb, very little over Repetitions: ***** 5 all the same exc. overage 10-11 3 i686 ext3 EDQUOT (good), cut at 1.1Gb (from 10-11 x86_64) More repetitions: EDQUOT EDQUOT 10-11 3 i686 ext3 EDQUOT (good), cut at 750Mb+ (from 10-0 x86_64) More repetitions: EIO EIO The client that gets EDQUOT is about 1.3x faster than the one getting EIO. All 3 machines are connected by a gigabit hub with little competing traffic, so network speed likely does not affect the results. Conclusion: The originally reported scenario on i686 has not self-healed, but instead of failing "every" time, it fails "most of the time" on the original client but never on a different client. When testing on x86_64 and ext3 I got no failures at all, either on the patched kernel or the standard kernel, but I got one failure (no EDQUOT, no EIO, no signal at all) with the combination of ext4, NFSv4, standard kernel, neither of which had failed before. Odysseus successfully squeezed information out of the god Proteus, and I think we need to learn from him to solve this bug. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.