On 2/27/14, 1:11 AM, Dave Chinner wrote: > On Wed, Feb 26, 2014 at 12:29:22PM -0600, Eric Sandeen wrote: >> On 2/25/14, 8:11 PM, Christoph Hellwig wrote: >>> On Mon, Feb 24, 2014 at 11:27:35PM -0600, Eric Sandeen wrote: >>>> xfs_set_maxicount() overflowed fairly easily for large filesystems >>>> and large maxicount; we started out by multiplying dblocks by >>>> the percentage, *then* dividing by 100, and never checked for >>>> an overflow. The calculations were also, IMHO, a little hard >>>> to follow. >>> >>> Would be useful to get this test case into xfstests.. >> >> Ok so I was going on Dave's assertion about that. ;) >> >> To overflow, we'd need dblocks * 100 to be > 2^64-1: >> >> so dblocks would need to be > (2^64-1)/100 >> >> for 4k blocks that's 655 exabytes. Maybe not so possible after all ;) > > Until the block count is corrupted by fsfuzzer? ;) > >> Dave, maybe just removing the open-code is enough here. > > Sure, but I still like the conversion to use mult_frac.... Ok, I do too. Just a bit resistant to fixing what ain't broke. I'll see if I can write up a test to be sure we're doing sane things statfs/growfs with the change. -Eric > Cheers, > > Dave. > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
