on 2023/1/10 15:19, Ziyang Zhang 写道: > On 2023/1/3 14:54, xuyang2018.jy@xxxxxxxxxxx wrote: >> >> >> on 2022/12/12 13:56, Ziyang Zhang wrote: >> >>> Sometimes "$((128 * dblksz / 40))" dirents cannot make sure that >>> S_IFDIR.FMT_BTREE could become btree format for its DATA fork. >>> >>> Actually we just observed it can fail after apply our inode >>> extent-to-btree workaround. The root cause is that the kernel may be >>> too good at allocating consecutive blocks so that the data fork is >>> still in extents format. >>> >>> Therefore instead of using a fixed number, let's make sure the number >>> of extents is large enough than (inode size - inode core size) / >>> sizeof(xfs_bmbt_rec_t). >> >> After this patch, xfs/083 and xfs/155 failed on my envrionment(6.1.0+ >> kernel). >> >> the 083 fail as below: >> 1 fuzzing xfs with FUZZ_ARGS=-3 -n 32 and FSCK_PASSES=10 >> 2 + create scratch fs >> 3 meta-data=/dev/sdb9 isize=512 agcount=4, >> agsize=529878 blks >> 4 = sectsz=512 attr=2, projid32bit=1 >> 5 = crc=1 finobt=1, sparse=1, >> rmapbt=0 >> 6 = reflink=0 bigtime=1 >> inobtcount=1 nrext64=0 >> 7 data = bsize=4096 blocks=2119510, >> imaxpct=25 >> 8 = sunit=0 swidth=0 blks >> 9 naming =version 2 bsize=4096 ascii-ci=0, ftype=1 >> 10 log =internal log bsize=4096 blocks=16384, version=2 >> 11 = sectsz=512 sunit=0 blks, >> lazy-count=1 >> 12 realtime =none extsz=4096 blocks=0, rtextents=0 >> 13 + populate fs image >> 14 MOUNT_OPTIONS = -o usrquota,grpquota,prjquota >> 15 + fill root ino chunk >> 16 + extents file >> 17 wrote 4096/4096 bytes at offset 0 >> 18 4 KiB, 1 ops; 0.0187 sec (212.891 KiB/sec and 53.2226 ops/sec) >> 19 + btree extents file >> 20 wrote 2097152/2097152 bytes at offset 0 >> 21 2 MiB, 2 ops; 0.0637 sec (31.370 MiB/sec and 31.3701 ops/sec) >> 22 + inline dir >> 23 + block dir >> 24 + leaf dir >> 25 + leafn dir >> 26 + node dir >> 27 + btree dir >> 28 + inline symlink >> 29 + extents symlink >> 30 + special >> 31 + local attr >> 32 + leaf attr >> 33 + node attr >> 34 + btree attr >> 35 + attr extents with a remote less-than-a-block value >> 36 + attr extents with a remote one-block value >> 37 + empty file >> 38 + freesp btree >> 39 wrote 4194304/4194304 bytes at offset 0 >> 40 4 MiB, 4 ops; 0.0941 sec (42.470 MiB/sec and 42.4696 ops/sec) >> 41 + inobt btree >> 42 + real files >> 43 FILL FS >> 44 src_sz 2052 fs_sz 8342940 nr 203 >> 45 failed to create ino 8578 dformat expected btree saw extents >> 46 failed to create ino 8578 dformat expected btree saw extents >> 47 (see /var/lib/xfstests/results//xfs/083.full for details) >> >> >> It seems this logic can't ensure to creat a btree format dir and it >> is a extent format dir. Or I miss something? >> >> >> Best Regards >> Yang Xu > > Hi all, > > __populate_xfs_create_btree_dir() will delete 50% files > after creating all the files if we set "missing" to 1(true). > This may transform the data fork from BTREE format to EXTENT > format by merging blocks. > > Without setting "missing", I find that xfs/083 xfs/155 xfs/273 > and xfs/495 pass. > > BTW, I have heard that Dave has wrote allocation speedup code > and thank Dave for looking into this as well. So, do you plan to send a patch to fix this code? Best Regards Yang Xu > > Regards, > Zhang > >
