On Fri, Apr 22, 2016 at 08:26:33AM +0800, Qu Wenruo wrote: > > > Mark Fasheh wrote on 2016/04/21 16:53 -0700: > >Thank you for the review, comments are below. > > > >On Wed, Apr 20, 2016 at 09:48:54AM +0900, Satoru Takeuchi wrote: > >>On 2016/04/20 7:25, Mark Fasheh wrote: > >>>+# Force a small leaf size to make it easier to blow out our root > >>>+# subvolume tree > >>>+_scratch_mkfs "--nodesize 16384" > >> > >>nodesize 16384 is the default value. Do you > >>intend other value, for example 4096? > > > >"future proofing" I suppose - if we up the default, the for loop below may > >not create a level 1 tree. > > > >If we force it smaller than 16K I believe that may mean we can't run this > >test on some kernels with page size larger than the typical 4k. > > --Mark > > > > > >-- > >Mark Fasheh > > > > > > Sorry for the late reply. > > Unfortunately, for system with 64K page size, it will fail(mount and > mkfs) if we use 16K nodesize. > > IIRC, like some other btrfs qgroup test case, we use 64K nodesize as > the safest nodesize. > > And for level 1 tree create, the idea is to use inline file extents > to rapidly create level 1 tree. > > 16 4K files should create a level 1 tree. > Although in this case, max_inline=4096 would be added to mount > option though. That all sounds good, thanks. The only thing about filling it completely with inline extents though is that we should be exercising qgroups a little harder. But maybe we can blow out the tree with inline extents and then add some actual data extents after that. --Mark -- Mark Fasheh -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
