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. Regards, Zhang
