Re: [PATCH V6 2/2] common/populate: Ensure that S_IFDIR.FMT_BTREE is in btree format

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> 
> 




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux